5 ms·
Java’s bytecode is JITted, which is a subtle distinction since there is an AOT translation step capabale of optimizations etc.
by kizer 7y ago
Java’s bytecode is JITted, which is a subtle distinction since there is an AOT translation step capabale of optimizations etc.
- _delirium 7y agoTechnically 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 https://openjdk.java.net/jeps/295.
- kizer 7y agoYou 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?
- earenndil 7y agoNope, because java is statically typed.
- laurencerowe 7y agoAvoiding 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.
- saagarjha 7y agoInterestingly, 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.
- fulafel 7y agoDepends on the JVM implementation. Eg with Graal you can have faster startup in Clojure, Java or other JVM language vs Node.
- kizer 7y agoSo 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.
- pjmlp 7y agoAOT 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.
- eatonphil 7y agoGood 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.
- kizer 7y agoI mean to say the bytecode is the input to the JIT.
- vardump 7y agoOther than startup time, isn't AoT more like pessimization, as runtime data can't be used to optimize performance?
- vips7L 7y agoRam usage is a big one for AOT java.
- garethrowlands 7y agoThat's true in Javascript because its highly dynamic nature isn't amenable to static analysis. But in general, AoT is usually a win, even though it doesn't have access to runtime data. C and Fortran are still the gold standard for performance, for example. One reason is that JITs are time constrained, even in long-running processes. Another is these languages are designed for AoT compilation. And there are ways for AoT compilation to have some, albeit limited, access to runtime data. One way is 'profile guided optimisation'. Another is inserting probes for different types of CPU.
- fulafel 7y agoPython is also bytecode compiled first.
- pjmlp 7y agoJava's bytecode can be JITted, AOT compiled to native code, stored in a cache and reused with PGO information, directly executed in hardware, or just plain interpreted. There are plenty of Java implementations to choose from. I wish professors would actually spend more than 5 minutes discussing how languages and implementations aren't the same thing.
- eatonphil 7y agoNot sure why you're downvoted. It's definitely difficult to talk about performance, for example, without keeping languages and implementations separate.