jdk 9 performance optimizations

forax at univ-mlv.fr forax at univ-mlv.fr
Sun Nov 15 17:32:03 UTC 2015


Vitaly, Kirk, 
there are several modes of ahead of time compilation. 

One, the one you are talking about, is to AOT the modules with a jlink backend and then at runtime to use the JIT to get the best of both world, 
in that case you can have a deopt when a branch was never taken or a class is loaded. 
I was talking about another mode, AOT with no JIT, like when you want to create an application on iOS, in that case i don't think that trying to go to the interpreter makes sense. 

regards, 
Rémi 

----- Mail original -----

> De: "Vitaly Davidovich" <vitalyd at gmail.com>
> À: "Kirk Pepperdine" <kirk at kodewerk.com>
> Cc: "hotspot-dev developers" <hotspot-dev at openjdk.java.net>, "Rémi Forax"
> <forax at univ-mlv.fr>
> Envoyé: Dimanche 15 Novembre 2015 17:41:42
> Objet: Re: jdk 9 performance optimizations

> It's not even just class loading invalidating speculative optimizations, it
> can be as pedestrian as a branch becoming reachable. I'd say class loading
> is more known than the latter; I've personally been surprised how some
> "simple" branches were pruned and cause deopt when reached. This is
> particularly a problem in daemons running with a low compile threshold. I
> understand the motivation for doing that, but sometimes it's very/overly
> aggressive.

> sent from my phone
> On Nov 15, 2015 3:26 AM, "Kirk Pepperdine" < kirk at kodewerk.com > wrote:

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


More information about the hotspot-dev mailing list