
Mysterious Android codebase commit - rogerthis
https://android.googlesource.com/platform/libcore.git/+/51b1b6997fd3f980076b8081f7f1165ccc2a4008
======
grizzles
To explain if you are just joining in: This pretty much means Oracle v Google,
a case with major ramifications for the industry has been settled out of
court. I don't see how this can be interpreted any other way.

~~~
grizzles
If this inference is right, I hope this means that Google will enable the web
community to use the JVM with or as an alternative to WebAssembly. Hotspot is
absolutely incredible technology, and it's competitors are still many years
away from coming close to matching it's capabilities.

~~~
ndesaulniers
And throw out the hard work __ALL__ browser vendors are doing TOGETHER on
WebAssembly? In favor of a VM that clearly has restrictions and is owned by a
litigious organization? Bloating browsers by adding another VM, which will
hurt throughput by having multiple GC's to synchronize?

The JVM ecosystem and Hotspot are certainly modern marvels, but there's
hurdles greater than the potential benefit.

~~~
grizzles
The JVM is already open source. If this matter has indeed been settled, then
the litigious organization issue might have been too. WebAssembly doesn't have
a GC, and probably won't for some time. It also doesn't have ~20 years of
performance tuning on different microarchitectures the way the JVM does.
Benefits include getting scala, clojure, jython, jruby, and about 30 other
languages working client side in the browser for free. Not to mention the
languages that have been statically compiled will run way faster than the
equivalent JS. That would be great for mobile, and the spread of the open web.

~~~
ndesaulniers
> The JVM is already open source.

I can picture Google's lawyers using that in court against Oracle.

> then the litigious organization issue might have been too

That might is a big MIGHT, the same kind that keeps browser vendors from
shipping various media codecs and news companies from using various media
streaming protocols.

> WebAssembly doesn't have a GC

The GC all browsers currently have and will not get rid of that I was
referring to was the JavaScript VM.

> It also doesn't have ~20 years of performance tuning on different
> microarchitectures the way the JVM does.

And the JVM doesn't have the start up performance of any JS VM. I would
estimate the number of exploits to be significantly higher for the JVM, but
worth less.

> Benefits include getting scala, clojure, jython, jruby, and about 30 other
> languages working client side in the browser for free.

JS is the most compiled to language in existence. Also, my point has been none
of this would be free. How do you integrate JVM with DOM? Who's going to
rewrite all that? Who's GC cleans up around here?

> Not to mention the languages that have been statically compiled will run way
> faster than the equivalent JS.

Are you talking about WebAssembly here? Cause it sounds like you are.

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

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

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

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

~~~
saurik
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...](http://www.cydiasubstrate.com/id/727f62ed-69d3-4956-86b2-bc0ffea110c1/)

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

~~~
saurik
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 was described.

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

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

------
quotemstr
This diff is more explicit about what's going on:

[https://android.googlesource.com/platform/libcore.git/+/aab9...](https://android.googlesource.com/platform/libcore.git/+/aab9271edee6cc8b4dd460977cad65efe52d16b0)

    
    
        Change dependency from libart -> libopenjdkjvm.
    

There are also diffs adding lambda support, tweaking various classes for
compatibility with applications that use reflection to access internal
capabilities, and fixing lots OpenJDK compatibility bugs.

Android still needs to run dex bytecode _somehow_ , so there are two
possibilities for how N will work.

Option one is that Android stick with ART and replaces Harmony with OpenJDK:
from a technical perspective, that wouldn't be the end of the world,
especially since the Harmony implementation is rather inefficient.

Option two is that Google ports Hotspot to run on Android and, then has
PackageManager convert dex bytecode _back_ to Java bytecode on device. That
would be awful, since ART is built for low-end devices and, well, Hotspot
isn't.

In favor of option one is that Google is still developing ART. In favor of
option two is Oracle being Satan incarnate.

I also wouldn't be surprised if Oracle has compelled Google to simply _ship_ a
copy of Hotspot, allowing developers to ship "authentic Java" APKs instead of
dex-bytecode ones, with the two environments running in parallel, with two
different zygotes.

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

~~~
pron
A JIT makes many tradeoffs but it is always capable of producing code _at
least as good_ as an AOT. How much better that code is depends on many
factors, such as the language, the application, and how much time/energy
you're willing to spend on optimization (the latter might lead to choosing to
generate code that's less optimized than an AOT).

A slightly bigger difference is not between JIT and AOT, but whether you can
dynamically load code at runtime or not. If not, that opens the door to some
whole-program optimizations, or, at least, removes the need for guards,
generated by the JIT, that are triggered when new code is loaded. In any case,
mobile applications don't load code dynamically.

~~~
Ded7xSEoPKYNsDd
> the latter might lead to choosing to generate code that's less optimized
> than an AOT

With ART compilation happening on the device (during installation instead of
runtime, but still) it suffers of the same trade-off of compilation
performance vs. performance of the generated code.

> In any case, mobile applications don't load code dynamically.

Android has a DexClassLoader. I'm sure some people use it.

~~~
pron
> it suffers of the same trade-off of compilation performance vs. performance
> of the generated code

Sure, which is why HotSpot _may_ be better.

> Android has a DexClassLoader. I'm sure some people use it.

I didn't know that (not an Android dev), but that only means that some form of
JITting may be beneficial anyway (depending on how popular this feature is).

------
gouggoug
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 there anybody checking that the source file imported haven't
been modified to include some kind of backdoor?

edit: replaced "cisco" with "juniper"

~~~
signa11
> ...recent cisco...

you mean juniper perhaps?

~~~
gouggoug
Woops... it's fixed!

------
blinkingled
The commit references ojluni. This relates to "luni" in Android source which
stands for lang util net io. Sounds like there are plans to replace the
harmony implementation with OpenJDK one. License differences are definitely
interesting but could be also related to performance and completeness - luni
is fairly small set of classes whereas ojluni import brings in a ton more.

But what I don't understand is why they're importing the full AWT API! That's
nuts.

~~~
lovelearning
I took a closer look at the commits, and I think it's not as bad as it looked
at first. They imported all classes of OpenJDK in the February commit posted
here, but then removed things like Swing at some later point of time. It's not
there in the master now.

~~~
blinkingled
Oh cool, so just a new libcore implementation based on openjdk, which should
be a good thing actually.

------
rogerthis
Maybe related:
[http://mail.openjdk.java.net/pipermail/announce/2015-Septemb...](http://mail.openjdk.java.net/pipermail/announce/2015-September/000200.html)

------
shams93
Its exciting to see all the goodies from java sound finally coming in. I could
care less about cobra though Im just glad we get better support for audio
coding from java without having to resort to jni and the native layer in
c/c++.

------
mahouse
What's mysterious? Legit curious.

~~~
wmf
Google has made a point of not using GPLed code (except Linux) or Sun/Oracle
code in Android, for technical and legal reasons. There's even a lawsuit about
it. So it's surprising to see GPLed Oracle OpenJDK code being committed
anywhere near Android.

~~~
exabrial
Interesting, isn't Android ASL?

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

~~~
maik
This one:
[https://android.googlesource.com/platform/libcore.git/+/aab9...](https://android.googlesource.com/platform/libcore.git/+/aab9271edee6cc8b4dd460977cad65efe52d16b0%5E%21/#F0)

    
    
        -LOCAL_SHARED_LIBRARIES += libart libnativehelper libdl
        +LOCAL_SHARED_LIBRARIES += libopenjdkjvm libnativehelper libdl
    

Replacing ART with OpenJDK JVM?!?

~~~
jevinskie
This is the one I was thinking of: [https://android-
review.googlesource.com/#/c/193835/](https://android-
review.googlesource.com/#/c/193835/)

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

------
bluesilver07
Change dependency from libart -> libopenjdkjvm.

Does this mean they're discarding ART for OpenJDK's VM?

~~~
Ambroos
It could. Not a bad thing, the HotSpot VM in OpenJDK is incredibly fast.

~~~
mirsadm
It does seem bizarre that Google would put in all the effort to develop ART
and then retire it so quickly.

------
bitmapbrother
On a tangential note, I guess this means Android is finally getting Java 8
support as well as Java 9, 10, 11, etc

------
aaronkrolik
Does this mean no more DVM?

~~~
LukeB_UK
Dalvik was replaced by ART in Lollipop

------
merb
So Lambda's are finally comming

~~~
ph0o
oh, i hope so!

------
dbwest
I was hoping this would be a link to code committed by AI. More of those,
please?

