Mysterious Android codebase commit • Hacker News Board

Re: Mysterious Android codebase commit

#131

Post by xolve » Tue, Dec 29, 2015, 10:17 PM UTC

pjmlp wrote: post #105

Nitramp wrote: post #90

Earlier quoted context omitted.

pjmlp: original poster above referred to Hotspot, not arbitrary JVMs. Clearly Android devices can run VMs with both JIT and AOT (they do, after all), what OP questioned was whether Hotspot in particular (not some arbitrary VM) is a good VM on a mobile device. Given Hotspot's somewhat underwhelming startup speed even on desktop class computers, I think that's a very reasonable technical question to ask, and not FUD in…

Hotspot requires as little as 128 KB RAM and 1 MB ROM http://www.oracle.com/technetwork/java/embedded/javame/embed... If one adds the GUI client APIs, then the whole SDK grows up to 5MB ROM. http://www.oracle.com/technetwork/java/embedded/javame/embed... Some commercial products using the above runtimes are the Gemalto's M2M modules or evaluation boards like the ARM Keil F200. But I expect Google fanclub to downvote…

Thanks for links and info.

I think comparability between Java (SE or ME) and Android would be a great win fit both communities :-)

Re: Mysterious Android codebase commit

#132

Post by [deleted] » Tue, Dec 29, 2015, 10:26 PM UTC

saurik wrote: post #99

deathanatos wrote: post #14

Earlier quoted context omitted.

This is a git repo, so "authored" tries to map to the person who wrote the content, and the "idea" of the commit, if there is such a thing. It's set when the commit is initially created, and for the most part not changed unless explicitly requested. The commit date is the actual time the commit object was made; this can differ if the commit is amended, rebased, cherry-picked, the result of a squash/fixup, etc. If a c…

First, read my response to the other person who provided a technical answer to this question. https://news.ycombinator.com/item?id=10806642 You have gone a little further and provided some general reasons as to "why this might happen", but you still seem to have missed the essence of the question, which was almost certainly more "can someone come up with some guess why, in this particular circumstance, given the theo…

[deleted]

Re: Mysterious Android codebase commit

#133

Post by xolve » Tue, Dec 29, 2015, 10:31 PM UTC

pron wrote: post #112

rewqfdsa wrote: post #109

Earlier quoted context omitted.

Okay, so can I modify it so that it doesn't conform to the Java specification? Can I modify it bit-by-bit until it's bytewise identical to Harmony? Of course I can't. Because if I do, Oracle will sue me. Oracle is lying. They claim to be offering free software, but will sue you once you take advantage of that freedom. It's a fucking trap. Do you really expect the technology community to embrace Oracle technology afte…

> Okay, so can I modify it so that it doesn't conform to the Java specification? Can I modify it bit-by-bit until it's bytewise identical to Harmony? Absolutely (on both counts, although if it is identical to Harmony you may be in violation of the license due to a collision between GPLv2 and ASL, as ASL imposes further restrictions which GPLv2 does not allow -- see the next paragraph). > Because if I do, Oracle will…

I am biased towards Oracle because I do want Android to be closer to orginal Java and wish both companies collaborate for future Java versions. However I do agree that Google's PR has tried to picture Google as victim. If we see Google specifically didn't choose OpenJDK to avoid GPL. So they wanted to make profits but avoid collaboration. If this makes them bring to use GPL, let it be.

Re: Mysterious Android codebase commit

#134

Post by xorcist » Tue, Dec 29, 2015, 10:44 PM UTC

pron wrote: post #81

grizzles wrote: post #78

Earlier quoted context omitted.

This is an interesting comment. GPL licensed code is divisible, so Google could technically achieve the same thing by adding a comment in the NOTICE file that said Api method signatures are Copyright Oracle, GPL, the rest is Apache. But the NOTICE file doesn't say anything about Oracle at all! Nor did they carry over the openjdk LICENSE file, which adds to the mysteriousness. I only did a cursory examination of the c…

> GPL licensed code is divisible, so Google could technically achieve the same thing by adding a comment in the NOTICE file that said Api method signatures are Copyright Oracle, GPL, the rest is Apache. That doesn't work. GPL is divisible (in fact, you can do whatever you want with the code), but the license must be applied to the entire deliverable, up to (excluding) classpath-linking which is explicitly exempted by…

> the fear that phone vendors would balk at a runtime that doesn't let them make proprietary changes

In retrospect, the ability for phone vendors to make proprietary changes to the system has been a huge problem for Google, Android as a platform, and the community in general.

Re: Mysterious Android codebase commit

#135

Post by lmm » Tue, Dec 29, 2015, 10:46 PM UTC

ndesaulniers wrote: post #129

lmm wrote: post #79

Earlier quoted context omitted.

All code can be a patent minefield. I predict we'll see patent trolls going after browser makers as soon as WebAssembly becomes popular. The fact that Java has a single, notoriously litigious owner actually works in its favour here - anyone trying to patent-troll Java will be issuing an invitation to Oracle's attack dogs, whereas WebAssembly could easily suffer a tragedy of the commons where no one browser vendor wan…

http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Req...

That only covers patents held by members of the working group.

Re: Mysterious Android codebase commit

#136

Post by Oletros » Tue, Dec 29, 2015, 11:47 PM UTC

xolve wrote: post #133

pron wrote: post #112

Earlier quoted context omitted.

> Okay, so can I modify it so that it doesn't conform to the Java specification? Can I modify it bit-by-bit until it's bytewise identical to Harmony? Absolutely (on both counts, although if it is identical to Harmony you may be in violation of the license due to a collision between GPLv2 and ASL, as ASL imposes further restrictions which GPLv2 does not allow -- see the next paragraph). > Because if I do, Oracle will…

I am biased towards Oracle because I do want Android to be closer to orginal Java and wish both companies collaborate for future Java versions. However I do agree that Google's PR has tried to picture Google as victim. If we see Google specifically didn't choose OpenJDK to avoid GPL. So they wanted to make profits but avoid collaboration. If this makes them bring to use GPL, let it be.

> If we see Google specifically didn't choose OpenJDK to avoid GPL.

As far as I know, when Android started to be developed, OpenJDK didn't exist

Re: Mysterious Android codebase commit

#137

Post by Oletros » Tue, Dec 29, 2015, 11:48 PM UTC

pron wrote: post #112

rewqfdsa wrote: post #109

Earlier quoted context omitted.

Okay, so can I modify it so that it doesn't conform to the Java specification? Can I modify it bit-by-bit until it's bytewise identical to Harmony? Of course I can't. Because if I do, Oracle will sue me. Oracle is lying. They claim to be offering free software, but will sue you once you take advantage of that freedom. It's a fucking trap. Do you really expect the technology community to embrace Oracle technology afte…

> Okay, so can I modify it so that it doesn't conform to the Java specification? Can I modify it bit-by-bit until it's bytewise identical to Harmony? Absolutely (on both counts, although if it is identical to Harmony you may be in violation of the license due to a collision between GPLv2 and ASL, as ASL imposes further restrictions which GPLv2 does not allow -- see the next paragraph). > Because if I do, Oracle will…

> [1]: I am willing to bet that very few people understand what the Oracle v. Google court case is all about,

And what it was about?

Re: Mysterious Android codebase commit

#138

Post by mike_hearn » Wed, Dec 30, 2015, 12:16 AM UTC

bitmapbrother wrote: post #114

quotemstr wrote: post #95

Earlier quoted context omitted.

Generalizations about which technique beats the other technique reflect a lack of technical maturity. Both have advantages, and you're doing a disservice by advocating the use of one or the other exclusively ignoring differences in environment, circumstances, and workload.

The very fact that Oracle has started to address the slow startup times of JVM applications by finally working on AOT compilation is an admission of the technical immaturity of the JVM. Also, the only relevant environment here is mobile and startup times are paramount in this environment.

The issue they're addressing with AOT is not startup time, it's warmup time and it's intended to help out, specifically, high frequency trading companies. Currently such companies have been known to engage in risky behaviour like, um, submitting bogus trades to the market and then immediately cancelling them in order to force JIT compilation of their codebase.

The HotSpot AOT work is actually a hybrid. The AOT compiler (Graal) has several modes and to get the best performance the AOT compiled code actually is compiled with profiling code. Thus it runs slower than it could do, but the profiling data is then used to trigger further JIT compilation in order to reach the best possible peak performance. So it ends up being a hybrid approach in which JITC still features heavily, and the AOT work is done to reduce the length of time taken to reach peak throughput.

Re: Mysterious Android codebase commit

#139

Post by richardwhiuk » Wed, Dec 30, 2015, 12:17 AM UTC

invalidname wrote: post #123

quotemstr wrote: post #95

Earlier quoted context omitted.

Generalizations about which technique beats the other technique reflect a lack of technical maturity. Both have advantages, and you're doing a disservice by advocating the use of one or the other exclusively ignoring differences in environment, circumstances, and workload.

Fair. But having worked on both and currently working on AOT I'd say I should be biased for AOT not against it... Startup time/warmup is obviously a well known JIT weakness but if its well written its just really hard to beat. E.g. if(x) { invokeMethodX() } else { invokeMethodY() } Say x is related to user details/preferences and for a specific install will never change... AOT can't do anything about that... JIT can…

AOT can do most of that as well - see likely() annotations.

And it's highly unlikely the JIT can get rid of the if entirely - it needs to check that it's assumptions hold true, otherwise it needs to drop out into the none-JITted code.

Re: Mysterious Android codebase commit

#140

Post by mike_hearn » Wed, Dec 30, 2015, 12:19 AM UTC

invalidname wrote: post #91

ndesaulniers wrote: post #36

Earlier quoted context omitted.

Pull an engine out of a car and it gets lighter, too.

Funny ;-) I actually worked for Sun/Oracle on VM's but on the embedded not hotspot team. The trick is actually simpler and its called MVM, which is something Sun kept avoiding on the desktop/server for some stupid reason but we did do it on mobile and it made startup almost instant. The trick is to share one VM instance between multiple apps. So when the OS starts you start the VM process and then fork with a lot of…

HotSpot has something called "Class Data Sharing" these days, in which pre-processed data is mmapped into the VM and shared between VMs as a result. More and more stuff is being put into the AppCDS files with the result that the VM has to do less and less work to start up. The jigsaw work also includes stuff like this via the jimage file format.