On 08/09/16 17:08, Krystal Mok wrote: > Thanks for your reply. It's good to know at least the known use cases > from IBM have indeed been discussed. > > On Thu, Sep 8, 2016 at 9:01 AM, Tim Ellison <t.p.elli...@gmail.com > <mailto:t.p.elli...@gmail.com>> wrote: > > On 07/09/16 23:45, Krystal Mok wrote: > > I see that on the JBS page, your most recent comment says it's been > decided > > that for JDK9 it's okay to deprecate and forRemoval=true, while also > > mentioning the uses of this class in IBM's implementation. > > > > Does that mean IBM has agreed on the deprecation of this class? > > Yep, I've seen those references and am ok with the deprecation in JDK9. > > > I thought J9 had features that allowed Java applications to do > > fine-grained control over the JIT compiler at runtime, e.g. force > > compilation of specified methods *at some certain point* in the > > program. > > Not sure what you are thinking of there Kris. We do implement the five > public methods on Compiler to do pretty much what you would expect: > > java.lang.Compiler.command(Object any) - this only does something for a > couple of custom arguments, most objects passed to it are simply > ignored. > > java.lang.Compiler.compileClass(Class<?> clazz) - the JIT will compile > all methods in the given class. These compilations are synchronous, i.e. > the application thread that called the API will wait until all > compilations are finished. > > This and the next one are the ones I was talking about: these calls can > be made at arbitrary points in time during Java program execution, so > they are "dynamic". > For instance, I may have a program that wishes to convey phase shift > properties to the VM, by calling once of these methods right before the > phase shift happens. That's something a static configuration means (e.g. > compiler configuration file) won't be able to do. Ditto for the > "waitOnCompilationQueue" command.
Yes, that is one way in which we can have an application indicate to the JIT that it is moving from start-up to run phase, and we have played with that. But come JDK9 and beyond there are much better opportunities for start-up optimizations that means these APIs can be removed without grief. Regards, Tim > java.lang.Compiler.compileClasses(String s) - the JIT will compile all > methods from classes that match the given string. > > java.lang.Compiler.disable() - disables all future JIT compilations. > > java.lang.Compiler.enable() - resumes JIT compilations. > > IMO dropping these APIs would not be a great loss. > > > What JEP 165 is proposing can only statically configure JIT behaviors > for > > HotSpot. The same approach doesn't seem to cover what J9 used to > support. > > > > Could you please share more background on the discussions that led to > the > > decision? > > As you would expect, IBM and Oracle talk regularly about all things > Java, and this topic was raised as a heads-up that it was coming to > OpenJDK. So there really isn't any background to the discussion. > > Regards, > Tim > (IBM Java team) > > > On Wed, Sep 7, 2016 at 2:50 PM, Stuart Marks > <stuart.ma...@oracle.com <mailto:stuart.ma...@oracle.com>> > > wrote: > > > >> Tomorrow's headline: Oracle Proposes To Remove Java JIT Compiler > >> > >> :-) > >> > >> > >> On 9/7/16 2:44 PM, Remi Forax wrote: > >> > >>> Yes, i like this patch :) > >>> > >>> Aleksey, It's worst than what you think because for a lot of people > >>> Compiler == java compiler and not JIT compiler so they try to > compile a > >>> .java file with the method compileClasses(String). > >>> > >>> I'm glad this class will disappear soon. > >>> > >>> Rémi > >>> > >>> ----- Mail original ----- > >>> > >>>> De: "Aleksey Shipilev" <aship...@redhat.com > <mailto:aship...@redhat.com>> > >>>> À: "Stuart Marks" <stuart.ma...@oracle.com > <mailto:stuart.ma...@oracle.com>>, "core-libs-dev" < > >>>> core-libs-dev@openjdk.java.net > <mailto:core-libs-dev@openjdk.java.net>> > >>>> Envoyé: Mercredi 7 Septembre 2016 23:34:02 > >>>> Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler > >>>> > >>> > >>> On 09/07/2016 11:52 PM, Stuart Marks wrote: > >>>> > >>>>> Please review this small patch to deprecate java.lang.Compiler for > >>>>> removal. > >>>>> > >>>> > >>>> Yes, +1. > >>>> This class is very confusing to have these days. > >>>> > >>>> -Aleksey > >>>> > >>> > >
