Hacker News Reader

Comment by saosebastiao | Hacker News Reader

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.

View on HN

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)

    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

Not all JIT compilation needs to be fast. I think it was hotspot that first does interpretation, then - when interpretation proves too expensive - switches over to a quick jit. And when code gets executed lots of times it runs jit again, this time with deep optimization settings.

What I personally don't understand: Why don't we cache JIT results between runs? That might be a worthwile optimization and even possible in the face of class loading.

It probably would be like running ngen on .net, just WITH performance statistics of a program. (Enabling specialization of calls for types commonly passed or eliminating constant expressions while keeping the generic version of a function around - that's hard in AOT as you need profiling information. I think sun's C/C++ compiler was able to do that for AOT, resulting in large speedups. But maybe it only used it for branch prediction).

Edit: What I forgot to add - I like the way you could always AOT things in .NET with ngen but also use a JIT where possible. Now that Java turned out to be owned by the evil empire and .NET the one by the company committed to open source - imagine reading that 10 years ago - I'm really curious in which way things will develop. And with all the new contenders as well. JVM (and .net) is not dead, but a lot of interesting alternatives are getting traction now.

> I think it was hotspot that first does interpretation, then - when interpretation proves too expensive - switches over to a quick jit. And when code gets executed lots of times it runs jit again, this time with deep optimization settings.

This is configurable, Hotspot can JIT right away when application starts, but then be prepared to wait a bit.

> What I personally don't understand: Why don't we cache JIT results between runs?

They do, just not the OpenJDK that many only care about.

All commercial JDKs support code caches between executions and AOT compilation.

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.

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.

That isn't 100% correct, you can write CLR plugins that control that behaviour.

Don't forget that AOT also means less memory -- no hotspot running and dynamically compiling code.

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

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

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

And there are alternative JVMs that are specifically designed for that use case that don't behave the same way.

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

> the JVM embedded into the Intel Management Engine coprocessor

First time I've heard that one. Got a source?

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

Reply on news.ycombinator.com