Java 9 performance optimizations

[Vitaly Davidovich]

Is there more info on aggressive lambda inlining? If it's what I think it
is, it would be very useful performance wise.

sent from my phone
On Oct 25, 2015 12:51 PM, "Jeroen Borgers" <jborgers at jpinpoint.com> wrote:

> Hi,
>
> One of the goals of Jigsaw I read here:
>
> http://openjdk.java.net/projects/jigsaw/goals-reqs/03#enable-ahead-of-time-whole-program-optimization-techniques
> is:
> *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?
>
> Thanks!
>
> -Jeroen
>