jdk 9 performance optimizations

[Christian Thalinger]

> 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
> 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
>> 
>> 
>>