6 ms·

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

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.
    - invalidname 11y ago
      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.).
      - richardwhiuk 11y ago
        AOT can do most of that as well - see likely() annotations. And it's highly unlikely the JIT can get rid of the if entirely - it needs to check that it's assumptions hold true, otherwise it needs to drop out into the none-JITted code.
      - strcat 11y ago
        Profile-guided optimization exists and is used by projects like Firefox is the real world. The advantage of JIT compilers is getting the profiling data dynamically, but that's usually going to be worse off than a well-tuned profiling suite especially if there are manual annotations.
- bitmapbrother 11y ago
  As far as Android is concerned - AOT is here to stay. And yes, I'm aware ART has a JIT and it's probably used for devices that cannot handle the overhead of AOT, but I imagine it's seldomly used considering the specs of today's phones and the requirements of Google's CTS.
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.

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.
  - invalidname 11y ago
    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.).
    - richardwhiuk 11y ago
      AOT can do most of that as well - see likely() annotations. And it's highly unlikely the JIT can get rid of the if entirely - it needs to check that it's assumptions hold true, otherwise it needs to drop out into the none-JITted code.
    - strcat 11y ago
      Profile-guided optimization exists and is used by projects like Firefox is the real world. The advantage of JIT compilers is getting the profiling data dynamically, but that's usually going to be worse off than a well-tuned profiling suite especially if there are manual annotations.
bitmapbrother 11y ago
As far as Android is concerned - AOT is here to stay. And yes, I'm aware ART has a JIT and it's probably used for devices that cannot handle the overhead of AOT, but I imagine it's seldomly used considering the specs of today's phones and the requirements of Google's CTS.

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.