Java 9 performance optimizations

Jeroen Borgers jborgers at
Sun Oct 25 16:51:13 UTC 2015


One of the goals of Jigsaw I read here:
*Enable ahead-of-time, whole-program optimization techniques*  -
The optimization techniques envisioned here include, but are not limited
to: Fast lookup of both JDK and application classes; early bytecode
verification; aggressive inlining of, *e.g.*, lambda expressions, and other
standard compiler optimizations; construction of JVM-specific memory images
that can be loaded more efficiently than class files; ahead-of-time
compilation of method bodies to native code; and the removal of unused
fields, methods, and classes. These kinds of techniques tend to work best
when JDK and application code is analyzed together, prior to run time.


   *Optimize existing code as-is* — It must be possible to apply the
   optimizer tool to existing code already packaged in traditional jar files,
   without changing those files.

   *Actual optimizations* — As a proof of concept, provide at least two
   optimizations that deliver nontrivial performance benefits.

My questions are:
* What is the current state? Which techniques/optimizations are already
implemented and available from the current ea JDK 9 or will be?
* Are there any new insights/developments in this area?
* I noticed in my JMH microbenchmark with parallelstream and lambda's that
it runs slightly faster on 9_b85 compared to 8_u66. Could this be caused by
more aggressive inlining of lambda's?
* It seems to me that some compilation and optimization work is moved from
runtime to link time, this will only be beneficial in limited cases, right?
Are there obvious cases?
* I don't really see why aggressive inlining and std optimizations can now
be more effective. Because there will be less de-optimization events needed
because of better predictability? Can in-lining now take place in two ways,
between platform modules and application? Through interfaces?



More information about the jigsaw-dev mailing list