jdk 9 performance optimizations

Wed Nov 11 18:58:30 UTC 2015

> On Nov 5, 2015, at 10:58 PM, Jeroen Borgers <jborgers at jpinpoint.com> wrote:
> 
> Hi Christian,
> 
> Thanks for the clarification, I over-simplified. Can you please shed some
> light on my questions? How can jigsaw help with AOT, inlining lambda’s?

I think the text you are quoting is more a blanket statement of what could be done.  Some of the listed optimizations might even be done on a class file level.

One area where JDK 9 can help is if all classes (JDK and application) are bundled together AOT compilation can optimize more optimistically.  Of course dynamic class loading can break all assumptions but that’s another story.

> I did my jug talk already yesterday, yet, I am curious.
> Thanks!
> 
> Jeroen
> 
> 2015-11-05 21:27 GMT+01:00 Christian Thalinger <
> christian.thalinger at oracle.com>:
> 
>> 
>>> 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
>>>> 
>>>> 
>>>> 
>> 
>> 