jdk 9 performance optimizations

Sun Nov 15 20:59:47 UTC 2015

I'm not overly familiar with Swift, but from the little I do know it seems
to have a better perf model; reified generics with specialization at use
site, struct/value types, etc.  It's also written to target a mature and
highly optimizing backend (LLVM) right from the start.

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

> Android Runtime (ART) or Swift performance are not that bad on mobile.
>
> Rémi
>
> ------------------------------
>
> *De: *"Vitaly Davidovich" <vitalyd at gmail.com>
> *À: *"Rémi Forax" <forax at univ-mlv.fr>
> *Cc: *"hotspot-dev developers" <hotspot-dev at openjdk.java.net>, "Kirk
> Pepperdine" <kirk at kodewerk.com>
> *Envoyé: *Dimanche 15 Novembre 2015 21:05:33
> *Objet: *Re: jdk 9 performance optimizations
>
> 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
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>
>>> >>>>
>>> >
>>>
>>>
>>
>