| |||||||||||||
You can't guess when the release of the product is going to happen => case closed, nothing to do here, move along...You can't guess when the release of the product is going to happen => case closed, nothing to do here, move along...Posted Apr 3, 2009 15:17 UTC (Fri) by forthy (guest, #1525)In reply to: You can't guess when the release of the product is going to happen => case closed, nothing to do here, move along... by khim Parent article: Android and Open Source (ABN)
Not in Android case. They use scheme where applications are started for a short period of time, do small amount of work and then killed. JIT will be detrimental for such usage and will actually suck MORE energy than interpreter. Hm, I've written lightweight JITs that take similar time to compile the code as an interpreter takes to execute it. Unless you have a completely loopfree application, the JIT-ed code is faster. People use these techniques today to JIT even JavaScript. It's a matter of tradeoffs, as usual. I've doing this sort of stuff for about 20 years now. Furthermore, as one comp.arch poster tells us in his footer: A lot in computing has to do with caching. Cache the JITed code, and reuse it later. You basically have to compile once per download. Gigabytes are cheap now, even on mobile phones. About this catch22-situation: Android is a distribution of various components, like a Linux kernel, WebKit, a JavaVM, and others. Most of that happens outside Google, anyways; all Google does is to adopt to their needs. This part is what should happen in the open, because merging back big lumps of patches is a PITA. The actual Andriod "distribution" itself can happen with whatever schedule Google likes to have.
(Log in to post comments)
|
|||||||||||||