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

91–100 of 170 posts

Re: Mysterious Android codebase commit

#91

Post by invalidname »

ndesaulniers wrote: post #36
exabrial wrote: post #32

Earlier quoted context omitted.

The startup performance of HotSpot is largely related to the SDK and class library. Remove it and you have a very expedient startup.

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 the JITted code already in place so you get almost instant startup and reasonable process isolation.

In mobile where there are some restrictions this is very practical. On the desktop/server this gets a bit tricky with bytecode manipulation, classloaders etc. But this is totally doable.

My personal uninformed theory is that Sun or Oracle didn't do this because they didn't care. MVM has two use cases: faster startup/lower overhead on desktops (they don't care about that).

Server efficiency in small scale deployments (which they don't care about either). AFAIK Google did some work on MVM for App Engine Java, but those are just rumors.

Re: Mysterious Android codebase commit

#92

Post by invalidname »

pjmlp wrote: post #89
makomk wrote: post #86

Earlier quoted context omitted.

I'm pretty sure those constrained devices are running bytecode interpreters that aren't nearly competitive with native code in terms of speed, with UIs that wouldn't cut it on even a low-end smartphone these days.

Then you should educate yourself, as they are running JIT and AOT code. I can provide links for product documentation and real products if you wish.

You are right.

The code for these embedded devices is JITted and I know because i worked on them. It also included some AOT but not much. In the past one of our guys benchmarked against an older version of Dalvik and had us at about 5x with those VM's.

To be fair they are not hotspot and it does have startup time issues because unlike the embedded version of our JIT's it doesn't feature MVM. However, a lot of this is configurable and easily fixable. Hotspot is remarkably tuneable and if MVM is added (which is possible) could probably beat ART in startup time as well...

ART is pretty fast by now though and pretty well understood. I don't think Google would switch to hotspot and I don't think it will need that for compliance either. They might just reuse some libraries that can be common and that's it.

Re: Mysterious Android codebase commit

#93

Post by invalidname »

quotemstr wrote: post #53
bitmapbrother wrote: post #52

Earlier quoted context omitted.

Option two wasn't even worth mentioning. There is absolutely no way Google is going to abandon ART and switch to a significantly less performant VM. AOT is here to stay.

> AOT is here to stay. No it isn't. Read the source. ART has a JIT now.

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

Re: Mysterious Android codebase commit

#94

Post by quotemstr »

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…

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.

Re: Mysterious Android codebase commit

#95

Post by quotemstr »

invalidname wrote: post #93
quotemstr wrote: post #53

Earlier quoted context omitted.

> AOT is here to stay. No it isn't. Read the source. ART has a JIT now.

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.

Re: Mysterious Android codebase commit

#96

Post by ZoFreX »

gouggoug wrote: post #50

I'm curious about big commits like this one: In the context of the recent juniper attack where some unauthorized code was committed without anybody noticing for years, it seems like it would be easy to hide a backdoor in such a big commit. How do you go about checking the integrity of the code when you have so many files? 8902 files were changed, most added, and the commit says it's just importing openJDK files. Is t…

The same way I validate scary merge commits: Do it myself, and compare what I get to what they got.

Re: Mysterious Android codebase commit

#97

Post by saurik »

kazinator wrote: post #16
0x0 wrote: post #7

Earlier quoted context omitted.

Also, why are the two timestamps so far off? Authored in February 2015 (almost a year ago!), but committed only in Nov 2015.

This means that a person named Piotr Jastrzebski created a commit in February. This is a different commit based on that one (not in the sense of revision ancestry, but in the sense of rewrite history): this commit is the N-th rewrite of Piotr's Jasterbski's commit, for some N > 0, and the rewriter ("committer") is Narayan Kamath. The rewrite can have different content: for instance, it can be altered to merge against…

You have answered how it is possible, not why it happened: that is like someone pointing out that this "mysterious" commit is actually quite easy to explain, as a commit is an object in a git database, and we have all the metadata to see who made this one: I am extremely well aware of how it works (I give lectures at UCSB about git where I start by explaining the internal file formats and work my way up to the various command line tools), but I still found the question here of "why was this authored in February but only landed in November" fascinating, given the speculation about Oracle.

Re: Mysterious Android codebase commit

#98

Post by zurn »

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…

> 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 the JITted code already in place so you get almost instant startup and reasonable process isolation.

Android does this, unless it changed recently. The common parent process is called "Zygote".

See eg http://www.elinux.org/Android_Zygote_Startup

Re: Mysterious Android codebase commit

#99

Post by saurik »

deathanatos wrote: post #14
0x0 wrote: post #7

Earlier quoted context omitted.

Also, why are the two timestamps so far off? Authored in February 2015 (almost a year ago!), but committed only in Nov 2015.

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 theories about this commit being influenced by a settlement of the Oracle lawsuit, this commit was authored in February but only landed in November?".

Re: Mysterious Android codebase commit

#100

Post by saurik »

quotemstr wrote: post #94
invalidname wrote: post #91

Earlier quoted context omitted.

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…

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

Post reply on HN