Hacker News Reader

Comment by pjmlp | Hacker News Reader

> Any examples of this?

Yes, Java and .NET.

Some JVM implementations, e.g. IBM J9, can save profile information between runs and use it for speeding up code generation, based on the complete history of the executable.

Google also started doing this when they rebooted ART into a mix of interpreter written in Assembly/JIT/AOT runtime. Starting with Android P they are even uploading profile information back to the store, so that similar devices can reach optimized AOT compiled code faster.

.NET Framework allows some control to save PGO data, and variants like that WinRT/UWP cloud compiler take it further.

> What prevents one from JITting AoT compiled binaries?

It relatively complex, versus just starting from bytecodes.

Hence why mainframes always took the approach of either JITing at installation time, or using microcoded CPUs.

Like on Burroughs, Xerox PARC and IBM cases.

View on HN

The IBM J9 JVM was open sourced and now lives as the Eclipse OpenJ9 project [1]. We rely on interpreter profiling (block frequency, and value profiling) before the JIT gets it's hands on the method. Once the JIT has determined the cost/benefit is right for a JIT compile we will run through an extended basic block ordering optimization which will lay out the code by block frequency calculated from the taken vs. not taken profiling information on the branch bytecodes given to us by the interpreter.

The persistence portion you mention between runs is our AOT capability in which we are able to cache JIT method compilations on disk and load them between different JVM invocations to greatly speed up startup performance. There is a recent series of blog posts on the AOT technology in OpenJ9 in [2].

[1] https://github.com/eclipse/openj9

[2] https://blog.openj9.org/category/jit/aot/

It'd be great if IBM and Google could contribute that into OpenJDK. Would that collide with project Panama [1] currently under way? (Or maybe that's a goal of the project?). Also, wasn't that the goal of Azul's ObjectLayout [2]?

If that could make it into the developer's IDE somehow, it'd be awesome. As in, the runtime detects which fields suffer from cache misses, tries a different layout, gathers data; and it all comes as fields being painted shades of blue/red in the IDE. It is one thing to have an optimized JPA object layout, but it is another to only have flat relevant data in the first place. Sort of like a database pushdown optimization through the developer, if you will.

[1] http://openjdk.java.net/projects/panama/

[2] https://www.azul.com/presentation/objectlayout/

I think you missed the question was about optimizing data layouts. Any references about that?

Reply on news.ycombinator.com