RFR(s): 4285505: deprecate java.lang.Compiler

[Tim Ellison]

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.ellison at gmail.com
> <mailto:t.p.ellison at 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.marks at oracle.com <mailto:stuart.marks at 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" <ashipile at redhat.com
>     <mailto:ashipile at redhat.com>>
>     >>>> À: "Stuart Marks" <stuart.marks at oracle.com
>     <mailto:stuart.marks at oracle.com>>, "core-libs-dev" <
>     >>>> core-libs-dev at openjdk.java.net
>     <mailto:core-libs-dev at 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
>     >>>>
>     >>>
> 
>