jdk 9 performance optimizations

Sun Nov 15 20:05:33 UTC 2015

Hi Remi,

What would the performance be of 100% AOT? Java pretty much requires
profile guided optimization to be performant, the language itself has a
very poor performance model.

sent from my phone
On Nov 15, 2015 12:32 PM, <forax at univ-mlv.fr> wrote:

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