Hacker News Reader

Comment by _delirium | Hacker News Reader

Technically yes, but the AOT step in practice does almost no optimizations and is just a direct translation, at least if you're using the mainstream javac. It's there just to simplify the VM/JIT, so the latter can read bytecode instead of textual source code.

There have been attempts at AOT compiling Java, but afaict they have very little usage. GCJ, now dead, was the main one for years. There's also a newer experimental compiler jaotc: https://openjdk.java.net/jeps/295.

View on HN

AOT compiling Java has lots of usage, including on my smartphone since Android 5.

Outside Android, it has always been available in commercial JDKs since the early 2000's.

GCJ was never the main one, it never went beyond a toy AOT compiler.

Anyone that cared about AOT compiling in Java would be paying big bucks to Excelsior JET, Aicas, Aonix, PTC, IBM, J/Rockit, Gemalto and a couple of smaller players.

Naturally in 20 years quite a few things changed, and now PTC, Aicas, IBM, Gemalto are the survivors, while MaximeVM graduated into GraalVM and there is a free beer layer for everyone not willing to pay for AOT compilers in Java.

Good history! But to reiterate for anyone missing it in there, look at GraalVM's AOT compiler today. It's OSS, well-funded, and mature: runs most large programs like Spring.

You seem to have more familiarity than me with Java :). So I guess V8 JITs some kind of p-code then? If V8 allowed full AOT comp. to the internal bytecode, then the perf would theoretically be around Java’s avg perf?

Avoiding the source parsing step would only provide a startup time performance win. JS engines tend to be faster than Java here already since it's something they've been heavily optimized for.

It's difficult for JS engines to match Java's performance without type information to work with. This is only discovered at runtime and the JIT'ed code for a function requires traps in case it is later called by parameters of a different type.

So the language itself is the limiting factor, being dynamically typed. I imagine sometimes what we’d get if typescript were natively supported. People could still write JS, or add the type information which would then allow higher performance to be achieved - approaching native or Java/C# levels.

Interestingly, one of the cases where Java JITs can beat native code are the same as JavaScript’s, and it’s when code can be speculatively monomorphized.

Depends on the JVM implementation. Eg with Graal you can have faster startup in Clojure, Java or other JVM language vs Node.

Nope, because java is statically typed.

Reply on news.ycombinator.com