5 ms·

Interesting that all the comparisons were with server frameworks. As if anybody ever cared about a few hundred megabytes of overhead on a server. Hell, even a b

Interesting that all the comparisons were with server frameworks. As if anybody ever cared about a few hundred megabytes of overhead on a server. Hell, even a bloated JVM implementation fits in most server L3 caches. On the desktop, laptop, phone, or embedded environment, the JVM is heavy. It starts up slow, jars carry around ridiculous amounts of dead dependencies, garbage collectors require immense amounts of tuning, etc. And we shouldn't really expect otherwise. If you can't even keep your VM in cache, how are you supposed to have fast application code? Specialty closed source JVM vendors have done wonders in terms of improving this problem...but it's still an uphill battle. AOT native compilation down to machine code is becoming more popular because of the proliferation of resource-constrained environments, and it will take time for new languages/compilers to take over, but take over they will.

froh42 10y ago
Haha, AOT native compilation. This comes back time and time again. AOT native results in slower runtimes for applications with one simple exception: startup time. In every other case a modern JIT compiler like the JVM will win due to gathering information and layered compilation. Where AOT really makes sense is for an interactive app on a mobile device where you don't care about the last millisecond of performance but startup times and even much more importantly: energy expenditure. (That's why google AOTing the apps on device startup is quite sensible) Most funnily Microsoft was heavily advertising AOT with .net framework 1.0 but in general switched to dynamic profiling and optimization in later versions of .net. (System assemblies that everybody uses during startup are AOT compiled using ngen, however) It is just not "one size fits all", depending on your platform and requirements you'd have completely different requirements to your virtual machine. What you want is different between interactive use and "batch processing" and between energy starved devices and big iron. Java - while ironically advertisted for "applets" years ago - is optimized for the latter case and there it really shines. On a server with long running processes AOT makes no sense at all. So what AOT will take over is phones. IOT devices. Everything were energy is at a premium and startup times need to be quick. Layered JIT compilation takes over where you want to squeeze out the last bit of total performance. (Even interactively, looking at you, Google V8 and Chakra)
- saosebastiao 10y ago
  I agree with most of what you say...AOT is far more of a competitive advantage for phones and other devices. But I'd argue that there are very few benefits of JIT that can't be achieved by AOT + PGO. A sound static type system nullifies the need for most of those benefits (like speculative type optimizations and deoptimizations). But it might have the upper hand in cases where profiling can't capture all of the possible optimizable workloads that the binary would see. Databases or other large programs that continuously specialize over the lifecycle of the process. But that is far more niche than most people realize.
- snuxoll 10y ago
  Later versions of .Net don't do dynamic profiling, the .Net CLR is much less sophisticated than the JVM, the first time you invoke an IL method it is compiled to machine code, and that same code will execute for the rest of the lifetime of that image.
  - pjmlp 10y ago
    That isn't 100% correct, you can write CLR plugins that control that behaviour.
- azinman2 10y ago
  Don't forget that AOT also means less memory -- no hotspot running and dynamically compiling code.
- quanticle 10y ago
  AOT native results in slower runtimes for applications with one simple exception: startup time. In every other case a modern JIT compiler like the JVM will win due to gathering information and layered compilation. That's not necessarily true. JIT compilation is severely constrained in the amount of analysis that it can do for the simple reason that JIT has to be fast. Fast enough to not noticeably slow down the app. Meanwhile, an AOT compiler can take all the sweet time it needs, and roam all over the program in order to discover optimizations. JIT compilers work very well on untyped languages like Smalltalk because the compiler can discover the type information at runtime, and then pre-compile the types that it sees most often. But that's not really that useful on the JVM, because Java is typed, as are most other JVM languages, with the exception of Clojure. Most funnily Microsoft was heavily advertising AOT with .net framework 1.0 but in general switched to dynamic profiling and optimization in later versions of .net. (System assemblies that everybody uses during startup are AOT compiled using ngen, however) Actually, with .Net Native, Microsoft is back to advertising AOT. http://blog.metaobject.com/2015/10/jitterdammerung.html http://blog.metaobject.com/2015/10/jitterdammerung.html
bhauer 10y ago
> On the desktop, laptop, phone, or embedded environment, the JVM is heavy. I'll half-agree with respect to phones and embedded environments since those are wildly variable and may include extremely low-specification platforms. But a desktop or laptop? The JVM launches in milliseconds on my desktop and laptop. The monstrous Eclipse IDE launches in about six seconds on my desktop, and about five seconds of that time is Eclipse loading various plugins and what-not, in what looks like a single-threaded manner. My desktop and laptop can both spin up Undertow and fire up a web-app from a Jar in about two seconds. I'm fairly sure Eclipse is just using an old clunky CMS garbage collector. I've never tuned it on my desktop or laptop. Maybe Neon is using G1 now. I don't know and don't care because it runs just fine. Maybe you've done something different with the JVM on desktops and laptops, but in my experience, on desktops and laptops, the JVM behaves more or less the same as it does on servers.
Matthias247 10y ago
The really interesting part of this: Java was actually designed for smaller embedded devices and not for servers.
- kasey_junk 10y ago
  And there are alternative JVMs that are specifically designed for that use case that don't behave the same way.
  - derefr 10y ago
    For examples: • the JVM on smart cards, e.g. EMV (chip) credit cards, or GSM cellular SIM cards • the JVM embedded into the Intel Management Engine coprocessor
    - MrBuddyCasino 10y ago
      > the JVM embedded into the Intel Management Engine coprocessor First time I've heard that one. Got a source?
      - niftich 10y ago
        Igor Skochinsky did some research into IME and has slides [1]. See slides 32-41. [1] http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub
smacktoward 10y ago
> As if anybody ever cared about a few hundred megabytes of overhead on a server Kids today! Sit down over here, and Grandpa will tell you about the days when a few hundred megabytes was more than your average server's entire storage capacity. Now, in those days you tied an onion to your servers, which was the style at the time...

froh42 10y ago

Haha, AOT native compilation. This comes back time and time again. AOT native results in slower runtimes for applications with one simple exception: startup time. In every other case a modern JIT compiler like the JVM will win due to gathering information and layered compilation. Where AOT really makes sense is for an interactive app on a mobile device where you don't care about the last millisecond of performance but startup times and even much more importantly: energy expenditure. (That's why google AOTing the apps on device startup is quite sensible) Most funnily Microsoft was heavily advertising AOT with .net framework 1.0 but in general switched to dynamic profiling and optimization in later versions of .net. (System assemblies that everybody uses during startup are AOT compiled using ngen, however) It is just not "one size fits all", depending on your platform and requirements you'd have completely different requirements to your virtual machine. What you want is different between interactive use and "batch processing" and between energy starved devices and big iron. Java - while ironically advertisted for "applets" years ago - is optimized for the latter case and there it really shines. On a server with long running processes AOT makes no sense at all. So what AOT will take over is phones. IOT devices. Everything were energy is at a premium and startup times need to be quick. Layered JIT compilation takes over where you want to squeeze out the last bit of total performance. (Even interactively, looking at you, Google V8 and Chakra)

saosebastiao 10y ago
I agree with most of what you say...AOT is far more of a competitive advantage for phones and other devices. But I'd argue that there are very few benefits of JIT that can't be achieved by AOT + PGO. A sound static type system nullifies the need for most of those benefits (like speculative type optimizations and deoptimizations). But it might have the upper hand in cases where profiling can't capture all of the possible optimizable workloads that the binary would see. Databases or other large programs that continuously specialize over the lifecycle of the process. But that is far more niche than most people realize.
snuxoll 10y ago
Later versions of .Net don't do dynamic profiling, the .Net CLR is much less sophisticated than the JVM, the first time you invoke an IL method it is compiled to machine code, and that same code will execute for the rest of the lifetime of that image.
- pjmlp 10y ago
  That isn't 100% correct, you can write CLR plugins that control that behaviour.
azinman2 10y ago
Don't forget that AOT also means less memory -- no hotspot running and dynamically compiling code.
quanticle 10y ago
AOT native results in slower runtimes for applications with one simple exception: startup time. In every other case a modern JIT compiler like the JVM will win due to gathering information and layered compilation. That's not necessarily true. JIT compilation is severely constrained in the amount of analysis that it can do for the simple reason that JIT has to be fast. Fast enough to not noticeably slow down the app. Meanwhile, an AOT compiler can take all the sweet time it needs, and roam all over the program in order to discover optimizations. JIT compilers work very well on untyped languages like Smalltalk because the compiler can discover the type information at runtime, and then pre-compile the types that it sees most often. But that's not really that useful on the JVM, because Java is typed, as are most other JVM languages, with the exception of Clojure. Most funnily Microsoft was heavily advertising AOT with .net framework 1.0 but in general switched to dynamic profiling and optimization in later versions of .net. (System assemblies that everybody uses during startup are AOT compiled using ngen, however) Actually, with .Net Native, Microsoft is back to advertising AOT. http://blog.metaobject.com/2015/10/jitterdammerung.html http://blog.metaobject.com/2015/10/jitterdammerung.html

bhauer 10y ago

> On the desktop, laptop, phone, or embedded environment, the JVM is heavy. I'll half-agree with respect to phones and embedded environments since those are wildly variable and may include extremely low-specification platforms. But a desktop or laptop? The JVM launches in milliseconds on my desktop and laptop. The monstrous Eclipse IDE launches in about six seconds on my desktop, and about five seconds of that time is Eclipse loading various plugins and what-not, in what looks like a single-threaded manner. My desktop and laptop can both spin up Undertow and fire up a web-app from a Jar in about two seconds. I'm fairly sure Eclipse is just using an old clunky CMS garbage collector. I've never tuned it on my desktop or laptop. Maybe Neon is using G1 now. I don't know and don't care because it runs just fine. Maybe you've done something different with the JVM on desktops and laptops, but in my experience, on desktops and laptops, the JVM behaves more or less the same as it does on servers.

Matthias247 10y ago

The really interesting part of this: Java was actually designed for smaller embedded devices and not for servers.

kasey_junk 10y ago
And there are alternative JVMs that are specifically designed for that use case that don't behave the same way.
- derefr 10y ago
  For examples: • the JVM on smart cards, e.g. EMV (chip) credit cards, or GSM cellular SIM cards • the JVM embedded into the Intel Management Engine coprocessor
  - MrBuddyCasino 10y ago
    > the JVM embedded into the Intel Management Engine coprocessor First time I've heard that one. Got a source?
    - niftich 10y ago
      Igor Skochinsky did some research into IME and has slides [1]. See slides 32-41. [1] http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub

smacktoward 10y ago

> As if anybody ever cared about a few hundred megabytes of overhead on a server Kids today! Sit down over here, and Grandpa will tell you about the days when a few hundred megabytes was more than your average server's entire storage capacity. Now, in those days you tied an onion to your servers, which was the style at the time...