jdk 9 performance optimizations
christian.thalinger at oracle.com
Thu Nov 5 20:27:16 UTC 2015
> On Nov 3, 2015, at 12:26 PM, Jeroen Borgers <jborgers at jpinpoint.com> wrote:
> 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
That’s not accurate; we do inlining but very limited.
> 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
> 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?
> 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
>> 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
>> 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 <
> 2015-11-03 23:21 GMT+01:00 Jeroen Borgers <jborgers at jpinpoint.com>:
>> One of the goals of Jigsaw that intrigue me, I read here: http://openjdk.
>> *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
>> * 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 hotspot-dev