jdk 9 performance optimizations

[Rémi Forax]

Hi Christian, 

Le 11 novembre 2015 19:58:30 CET, Christian Thalinger <christian.thalinger at oracle.com> a écrit :
>
>> 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.

If your application is a trading application you don't want your application to dynamically load an unknown class.

My opinion is that the AOT should come with a flag les say 'closed world'  that throw an exception if an unknown class force the runtime to go to a deopt.

cheers,
Rémi

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