Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mysterious Android codebase commit

android.googlesource.com

Post reply on HN
Print view View original

121–130 of 170 posts

Re: Mysterious Android codebase commit

#121

Post by pron »

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 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.

Not at all. If you listen to the talk introducing that work, you'll see that it is designed to address a very particular (and relatively unusual) use-case, which is important to some specific (yet lucrative) Oracle customers.

Re: Mysterious Android codebase commit

#122

Post by invalidname »

saurik wrote: post #116
quotemstr wrote: post #101

Earlier quoted context omitted.

It's not the same thing at all. Android first makes a process template, then takes clippings for each process it wants to run. That's not the same as running different applications in the same process.

The person who worked for Sun/Oracle, the one who first mentioned this technique earlier in this thread, was quite clear that the technique involves loading a single VM and then " fork[ing] with a lot of the JITted code already in place and reasonable process isolation ". You are, of course, correct that this is not the same as "running different applications in the same process", but that is not the technique that w…

FYI that's how we implemented MVM in CDC mobile which isn't necessarily applicable for hotspot.

The MVM RFE for hotspot has been something desktop developers have asked for since JDK 1.2 days. It sort of got sidelined when the JDK started sharing loaded classes (the rt.jar) which is important but not quite MVM. Even the weakest of Android devices is probably more powerful than our "smartphone" targets in terms of heap. Using process isolation was often not an option back then since common OS's at the time (symbian) didn't really have isolation.

Re: Mysterious Android codebase commit

#123

Post by invalidname »

quotemstr wrote: post #95
invalidname wrote: post #93

Earlier quoted context omitted.

As a guy who used to work for Sun on JITted code and is now doing AOT for https://www.codenameone.com/ I've got to say that JIT always beats AOT in runtime. It can also beat it in startup when properly designed (MVM, caching etc.).

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 inline invokeMethodX() then optimize across methods and eliminate the if altogether. This isn't some theoretical exercise... Its stuff that exists today in JIT's. AOT provides consistency which is a good thing, you can write low level code (e.g. C can be handcoded to a level that's pretty great) so I'm mostly talking about higher level languages (Java etc.).

Re: Mysterious Android codebase commit

#125

Post by bitmapbrother »

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…

This is perhaps the most interesting comment on this topic. The implications for such a licensing change would be enormous for the development community, I believe. The days of OEM's not releasing their source code, for changes to the Android ASL parts, may finally be over.

I'm curious, though, as to why you believe Google would expend less effort developing the runtime considering the different trajectories of ART and the JVM.

Re: Mysterious Android codebase commit

#126

Post by pron »

bitmapbrother wrote: post #125
pron wrote: post #81

Earlier quoted context omitted.

> 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…

This is perhaps the most interesting comment on this topic. The implications for such a licensing change would be enormous for the development community, I believe. The days of OEM's not releasing their source code, for changes to the Android ASL parts, may finally be over. I'm curious, though, as to why you believe Google would expend less effort developing the runtime considering the different trajectories of ART a…

> I'm curious, though, as to why you believe Google would expend less effort developing the runtime considering the different trajectories of ART and the JVM.

Because the runtime is much more than just the VM. If you look at the breakdown of the JDK source tree[1], you'll see that it's 77% Java and only 18% C/C++ (although the Android ecosystem is already making indirect use of some of that Java code, when it uses tools like javac, javadoc etc.). Also, Google might choose to use HotSpot or parts of it instead of or in addition to ART.

Of course, all of this is pure speculation (and wishful thinking) on my part.

[1]: https://github.com/dmlloyd/openjdk

Re: Mysterious Android codebase commit

#127

Post by overgard »

greggman wrote: post #33
overgard wrote: post #31

Earlier quoted context omitted.

> WebAssembly doesn't have a GC, and probably won't for some time. Yeah... because it's assembly. That's the whole point. You don't WANT a GC. It would be the wrong layer to place a GC in. Ask most professional game developers if they would consider using a platform with a GC. They won't, because you can't build a realtime system without stuttering if you're dealing with a GC.

1000s of games have shipped with gc. Every Unreal and Unity game uses gc. Every XNA game used gc. Many of the largest most popular AAA games use gc. So yes we can ask professional game devs if they want a gc. Most will say "yes". Like any tool you know when to use them and when not to

I wasn't saying game developers never use GC's, I was saying they don't want the platform to make that decision for them. I'm not against GC at a language level, but I am against it in something that's supposed to be "assembly". It's just the wrong layer to place a GC in.

Anyway people are getting caught up in games, I'm just using that as one example of many where a GC may not be wanted.

Re: Mysterious Android codebase commit

#128

Post by jevinskie »

maik wrote: post #59
jevinskie wrote: post #19

I recall seeing a "libopenjdkjni" related review on android-review earlier today. It was just a makefile change though, no real code diff. Unfortunately I can't find the review anymore.

This one: https://android.googlesource.com/platform/libcore.git/+/aab9... -LOCAL_SHARED_LIBRARIES += libart libnativehelper libdl +LOCAL_SHARED_LIBRARIES += libopenjdkjvm libnativehelper libdl Replacing ART with OpenJDK JVM?!?

This is the one I was thinking of: https://android-review.googlesource.com/#/c/193835/

It was 'libopenjdkjvm' not 'libopenjdkjni' as I recalled.

Re: Mysterious Android codebase commit

#129

Post by ndesaulniers »

lmm wrote: post #79
rdtsc wrote: post #66

Earlier quoted context omitted.

> The JVM is already open source. From what I understand open source and imunity from litigation are orthogonal. Open source code and still be a patent minefield.

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...

Re: Mysterious Android codebase commit

#130

Post by ndesaulniers »

saurik wrote: post #100
quotemstr wrote: post #94

Earlier quoted context omitted.

MVM relies on the runtime system to enforce security isolation. In a system like Android that allows unrestricted loading of native code, this scheme can't work, since there's no way to get arbitrary native code to play along with the runtime security model. Personally, I feel much more confident with the kernel enforcing application isolation than I would feel about relying on the Java security model.

As a sibling comment pointed out, Android already does this. To learn (an insane amount of) more detail about how this works, read this article I wrote a while back on how Process Loading on various systems is optimized. http://www.cydiasubstrate.com/id/727f62ed-69d3-4956-86b2-bc0...

That was a great read! Thanks for sharing!
Post reply on HN