5 ms·

This diff is more explicit about what's going on: https://android.googlesource.com/platform/libcore.git/+/aab9271edee6cc8b4dd460977cad65efe52d16b0 https://andr

This diff is more explicit about what's going on: https://android.googlesource.com/platform/libcore.git/+/aab9271edee6cc8b4dd460977cad65efe52d16b0 https://android.googlesource.com/platform/libcore.git/+/aab9... 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.

quotemstr 11y ago
dang, want to change the headline from "mysterious commit" to "Google switches Android to OpenJDK"?
bitmapbrother 11y ago
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.
- quotemstr 11y ago
  > AOT is here to stay. No it isn't. Read the source. ART has a JIT now.
  - invalidname 11y ago
    As a guy who used to work for Sun on JITted code and is now doing AOT for https://www.codenameone.com/ 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.).
    - quotemstr 11y ago
      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.
      - bitmapbrother 11y ago
        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.
        pron 11y ago
        > 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.
        mike_hearn 11y ago
        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.
- deleted 11y ago
  [deleted]
- pron 11y ago
  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 11y ago
    > 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 11y ago
      > 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).
  - bitmapbrother 11y ago
    Of course a JIT is capable of producing code as good as an AOT and perhaps even better since it can capture more profiling data. The problem with a JIT is the startup time and this has not gone unnoticed by Oracle as even they've started working on AOT.
    - pron 11y ago
      Not startup but warmup (i.e. the time until the application is fully optimized). There are other problems with a JIT on small devices, such as increased memory and energy consumption (each may be significant or not, depending on how the JIT works). I am a big fan of JITs, but as with everything in software, it is a tradeoff.
deleted 11y ago
[deleted]
- quotemstr 11y ago
  You're confused on several points. First, Java VMs don't "generate bytecode": if they have JITs, they generate machine code. Otherwise, they just interpret bytecode. Second, you're confusing OpenJDK-the-set-of-libraries with Hotspot-the-VM. OpenJDK probably isn't a disaster for performance: not because it's good, but because Harmony was abysmal. (Count the allocations inside String.format.) Switching from ART to Hotspot is not a clear win. ART does AOT compilation (at least some of the time), is integrated with the system runtime (doing a compacting GC pass on app switch, for example), and interacts properly with Android's zygote-based start scheme. (It doesn't, for example, COW away all the memory benefits as a naive fork would.) Both ART and Hotspot have pretty good code generators and allocators. There's no reason to support that the latter would be a better choice, technically, than the former. Google seems to agree, since ART development is ongoing. Please read more about VM implementation schemes instead of continuing to make unfounded assertions (like "Java is based on the idea of a JIT" and "virtual method calls are slow without a JIT").
  - crustycoder 11y ago
    "(It doesn't, for example, COW away all the memory benefits as a naive fork would.)" That's not the case any longer, posix_spawn() is used on recent JVMS rather than fork().
scrollaway 11y ago
As a sidenote, giant commits including giant dependencies in the tree are the perfect time to include new backdoors. Nobody will know who really introduced them. Wish people didn't do that. Separate repos are not hard to create...
drtse4 11y ago
> Harmony implementation is rather inefficient. A lot of stuff have been fixed or improved from the original Harmony code over the years, performance-wise the android implementation of the core library and the openjdk implementation are now similar (openjdk has a few more intrinsics and makes a more liberal use of native methods).
pjmlp 11y ago
> That would be awful, since ART is built for low-end devices and, well, Hotspot isn't. That is plain Google FUD to not follow the Java standards. There are lots of embedded devices, more constrained than Android phones, running commercial compliant JVMs like Atego, Jamaica, J9 among many others. Also Sun/Oracle Hotspot implementations have existed since the J2ME and Embedded Java early days for devices with just a few hundred KBs, not a few hundred MB like Android.
- makomk 11y ago
  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.
  - pjmlp 11y ago
    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.
    - Nitramp 11y ago
      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 any way.
      - pjmlp 11y ago
        Hotspot requires as little as 128 KB RAM and 1 MB ROM http://www.oracle.com/technetwork/java/embedded/javame/embed-me/documentation/me-e-otn-faq-1852008.pdf 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/embedded-client/overview/oraclejavameembeddedclient-2177392.html 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 me.

quotemstr 11y ago

dang, want to change the headline from "mysterious commit" to "Google switches Android to OpenJDK"?

bitmapbrother 11y ago

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.

quotemstr 11y ago
> AOT is here to stay. No it isn't. Read the source. ART has a JIT now.
- invalidname 11y ago
  As a guy who used to work for Sun on JITted code and is now doing AOT for https://www.codenameone.com/ 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.).
  - quotemstr 11y ago
    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.
    - bitmapbrother 11y ago
      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.
      - pron 11y ago
        > 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.
      - mike_hearn 11y ago
        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.
deleted 11y ago
[deleted]
pron 11y ago
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 11y ago
  > 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 11y ago
    > 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).
- bitmapbrother 11y ago
  Of course a JIT is capable of producing code as good as an AOT and perhaps even better since it can capture more profiling data. The problem with a JIT is the startup time and this has not gone unnoticed by Oracle as even they've started working on AOT.
  - pron 11y ago
    Not startup but warmup (i.e. the time until the application is fully optimized). There are other problems with a JIT on small devices, such as increased memory and energy consumption (each may be significant or not, depending on how the JIT works). I am a big fan of JITs, but as with everything in software, it is a tradeoff.

deleted 11y ago

[deleted]

quotemstr 11y ago
You're confused on several points. First, Java VMs don't "generate bytecode": if they have JITs, they generate machine code. Otherwise, they just interpret bytecode. Second, you're confusing OpenJDK-the-set-of-libraries with Hotspot-the-VM. OpenJDK probably isn't a disaster for performance: not because it's good, but because Harmony was abysmal. (Count the allocations inside String.format.) Switching from ART to Hotspot is not a clear win. ART does AOT compilation (at least some of the time), is integrated with the system runtime (doing a compacting GC pass on app switch, for example), and interacts properly with Android's zygote-based start scheme. (It doesn't, for example, COW away all the memory benefits as a naive fork would.) Both ART and Hotspot have pretty good code generators and allocators. There's no reason to support that the latter would be a better choice, technically, than the former. Google seems to agree, since ART development is ongoing. Please read more about VM implementation schemes instead of continuing to make unfounded assertions (like "Java is based on the idea of a JIT" and "virtual method calls are slow without a JIT").
- crustycoder 11y ago
  "(It doesn't, for example, COW away all the memory benefits as a naive fork would.)" That's not the case any longer, posix_spawn() is used on recent JVMS rather than fork().

scrollaway 11y ago

As a sidenote, giant commits including giant dependencies in the tree are the perfect time to include new backdoors. Nobody will know who really introduced them. Wish people didn't do that. Separate repos are not hard to create...

drtse4 11y ago

> Harmony implementation is rather inefficient. A lot of stuff have been fixed or improved from the original Harmony code over the years, performance-wise the android implementation of the core library and the openjdk implementation are now similar (openjdk has a few more intrinsics and makes a more liberal use of native methods).

pjmlp 11y ago

> That would be awful, since ART is built for low-end devices and, well, Hotspot isn't. That is plain Google FUD to not follow the Java standards. There are lots of embedded devices, more constrained than Android phones, running commercial compliant JVMs like Atego, Jamaica, J9 among many others. Also Sun/Oracle Hotspot implementations have existed since the J2ME and Embedded Java early days for devices with just a few hundred KBs, not a few hundred MB like Android.

makomk 11y ago
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.
- pjmlp 11y ago
  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.
  - Nitramp 11y ago
    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 any way.
    - pjmlp 11y ago
      Hotspot requires as little as 128 KB RAM and 1 MB ROM http://www.oracle.com/technetwork/java/embedded/javame/embed-me/documentation/me-e-otn-faq-1852008.pdf 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/embedded-client/overview/oraclejavameembeddedclient-2177392.html 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 me.