jdk 9 performance optimizations

[Jeroen Borgers]

I posted in jigsaw-dev list before:

I found this interesting presentation "Java goes AOT" from JVM Language
Summit: https://www.youtube.com/watch?v=Xybzyv8qbOc

As presented by Christiaan Thalinger from HS compiler team, AOT is used
with Graal to reduce startup time and quicker peakperformance (tiered).
Currently they don't do any inlining in AOT yet because compilation time
blows up by inlining everything since no profiling information is available
yet. I guess modules and knowing dependencies can help here to reduce this.
Besides test running to generate profiling data.

Regards, Jeroen
Bijlagen
Voorbeeld van YouTube-video JVMLS 2015 - Java Goes AOT weergeven
JVMLS 2015 - Java Goes AOT
Vitaly Davidovich
13:09 (10 uur geleden)
aan Jeroen, jigsaw-dev

Yes, I had seen Chris' presentation as well.  Certainly modularization will
help AOT in many ways.  But, I'm particularly interested on the JIT side.
What was meant by aggressive lambda inlining, for example? Can anyone point
at some additional info?

Thanks

sent from my phone
Paul Sandoz <paul.sandoz at oracle.com>
13:32 (9 uur geleden)
aan jigsaw-dev
Hi Vitaly,

Probably worth sending an email to the hotspot-dev at openjdk.java.net <mailto:
hotspot-dev at openjdk.java.net>

> On 3 Nov 2015, at 13:09, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
> Yes, I had seen Chris' presentation as well.  Certainly modularization
will
> help AOT in many ways.  But, I'm particularly interested on the JIT side.
> What was meant by aggressive lambda inlining, for example? Can anyone
point
> at some additional info?
>

I presume it in part might relate to cracking open the lambda “box”
implementing the targeted functional interface to obtain the underlying
method containing the lambda body, generated by javac, that the box defers
to, then subsituting the indy call to an invocation of that underlying
method. Cue lots of hand waving…

Maybe more clues in Oleg Pliss’s Closures on Embedded JVM presentation at
JVMLS 2014:

  http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf <
http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf>
--------

Thanks,

Jeroen

2015-11-03 23:21 GMT+01:00 Jeroen Borgers <jborgers at jpinpoint.com>:

> Hi,
>
> One of the goals of Jigsaw that intrigue me, 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.
>
> I am curious about the following:
> * What is the current state of this? Which techniques/optimizations are
> already implemented and available from the current ea JDK9 or will be?
> * Are there any new insights/developments in this area?
> * I noticed in my JMH microbenchmark with parallel stream 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 /AOT time, yet, we don't have profiling information
> there, so this will be limited, right? Are there obvious cases which work
> well?
> * 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
>
>
>