jdk 9 performance optimizations

[Kirk Pepperdine]

Hi Remi,

In general I think that it’s not well known that dynamically loading a class often results in a de-optimization storm.

Regards,
Kirk

> On Nov 12, 2015, at 9:20 AM, Rémi Forax <forax at univ-mlv.fr> wrote:
> 
> 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
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>