Thought this was a pretty interesting announcement by Oracle:
Xybzyv8qbOc
I don’t have an internet connection that can handle videos. -__-’ Can anyone give me a TL;DR?
Tbh I thought that presentation sucked.
This presentation was much better:
https://www.youtube.com/watch?v=uNgAFSUXuwc (completely different topic ofc 
I needed some background to find out what this discussion was about.
This article has a lot of good information about Java “executable” options, with a section on AOT compilers. It has a comparison of Excelsior and Gnu versions. From 2014. (The author works at Excelsior.)
http://www.excelsior-usa.com/articles/java-to-exe.html
I also expected more from the presentation. There were some rumors about that for some time 
but the actual implementation he’s explaining looks weird to me. Why not just give a way to offline pre-compile it to native code, then it actually can take more time and it would be a one time operation but well… it will be a commercial feature anyways so nobody really cares.
This is actually a very different kind of AOT compared to what Oracle is working on.
I never watch videos…too much time commitment vs. information. So what do they mean? Compiler memorization? Starting to perform transforms at compile time? A change in classfile format? Or the boring thing of AOT to native?
The very long and meandering video talks about a quite peculiar form of AOT compilation they’re working on which appears to coexist with the JIT stuff.
It does appear to be a peculiar direction to take and is certainly nothing anybody particularly wants… everyone currently content with the JVM as implemented is, well, content. Anyone who needs AOT compilation… needs straightforward, simple, full AOT compilation. There’s not much of a middle ground. So this is a bit of a perplexing development really.
Cas
The parts that I watched discussed caching the JIT-compiled hot-spot code to disk. But apparently this presents difficulties due to class-loading order and other traps.
So the speaker experimented with an ahead-of-time static compile which somehow works with the JIT functionality.
Apparently the proposed optimisations could not be fully realised due to budget and time constraints so the speed-ups were less than hoped for. Also, the added code complexity worked against the start-up time savings.
As an incremental improvement I think it’s a good thing. Doing away with the JIT re-compilation of java code seems like a pretty obvious optimisation. Any start-up-time savings are very welcome, in whatever form.
I agree. I can’t understand why people like the Khan Academy videos to learn maths for that reason. What’s more, the video author can’t easily edit and improve the video after its recorded. Also, search engines can’t index the video.
Ok: so it’s compiler memorization.
Pretty much. But as I say… it solves a problem people don’t really have. Startup time is insignificant next to run duration for any non-trivial application (and by “insignificant” I mean that no-one is really so bothered that I know of who would experience some sort of life-changing epiphany should Eclipse start up in 5s instead of 8s). For trivial applications the C1 compiler appears to be roughly the same startup time as these experiments. And for those hi-frequency traders who don’t want a compile to unexpectedly issue right at the point they perform their first trade - well that’s what Excelsior JET is for.
Cas
I agree that AOT compilation using Excelsior JET appears to be a better solution.
But startup time is one of the worst aspects of Java programs and creates negative user experiences even for non-trivial programs.
Java GUI freeze when a button is clicked for the first time is very irritating and that’s due to JIT compilation.
Native programs seem to be able to start almost instantaneously.
I’m sorry, but I’ve never actually seen this behaviour. The only thing that causes Java UIs to freeze is when people don’t know how (or even when) to code multithreaded UIs.
Eclipse starts up here in 8 seconds and it’s probably the biggest Java application anyone is ever going to run. An 8 second wait first thing in the morning isn’t really going to cause me to tear my hair out in rage and frustration. Likewise reducing that delay to 5 seconds isn’t going to save me any of the hair I haven’t lost in the first place. It all smacks of a bizarrely contorted form of premature optimisation.
Cas
UI freezes are normally not because of JIT recompilation but GC or similar things, or just as princec said: because people write crappy UI code.
Intellij was the first program to prove that Swing UIs are not inherently slow.
Even GC freezes are largely a myth. In Real Life, GC “freezes” beyond for example a minor intermittent jitter in a game’s frame rate just don’t happen. Idle UIs just don’t produce garbage in any measurable form.
Cas
I think it’s a mistake to call “compiler memorization” AOT.
I agree that many GUI programmers don’t multi-thread their GUI’s enough to hide resource-loading and other freeze scenarios.
I stand corrected that the GUI slowness is probably not due to JIT compilation, but rather the lack of it.
Interpreted non-openGL software-only graphics GUI code is very slow before it has been JIT-compiled.
This is why GUI’s often feel unresponsive until they’ve been ‘warmed up’. This is an issue for custom look and feels that tax the software rendering loops, such as the Substance swing look and feel which I liked a lot but would take a while to become fast and responsive.
Since you use Eclipse, which uses the SWT framework’s native GUI components, you probably don’t see this.
I think that start-up time improvements through caching or static compilation is a great leap forward, in the Neil Armstrong sense, not the Mao Zedong sense 8)
This initial slowness definitely happens with audio coding, and is well known enough to get special mention in a very good article on low-latency audio coding in Java. But there is a work-around: one can code a silent tone to play prior to the first time that audio is heard. Though, that consumes a bit of time, too.
As a developer using Eclipse, I agree that a few extra seconds of startup time is not a problem. But I can also see where the transition from interpreted to compiled could color a common user’s experience of Java, and unfairly affect its reputation.
What they call AOT is AOT. They compile to native code without any kind of runtime information but the JIT is able to recompile afterwards. That is their current architecture, however it feels wrong - still 
If you code a game you anyways have a very clear hot path, just lower the JIT threshold to 100 or so
Humm. So there is no compiler memorization in this talk? javac is generating native code in addition to bytecodes? I’m getting the impression I’m glad to not have watched the video