jdk 9 performance optimizations

Sun Nov 15 16:41:42 UTC 2015

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