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

[Krystal Mok]

Hi Tim,

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

Thanks,
Kris


> 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>
> > 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>
> >>>> À: "Stuart Marks" <stuart.marks at oracle.com>, "core-libs-dev" <
> >>>> 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
> >>>>
> >>>
>