[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-hotspot-runtime-dev
Subject: Re: RFC: JWarmup precompile java hot methods at application startup
From: yumin qi <yumin.qi () gmail ! com>
Date: 2019-04-29 16:35:15
Message-ID: CAOEheN5ewjdZdhrDsQNdB6udWQk4JjT7kmVEhhG0R7BQCBewZA () mail ! gmail ! com
[Download RAW message or body]
HI, David
Thanks for comments.
On Sun, Apr 28, 2019 at 6:50 PM David Holmes <david.holmes@oracle.com>
wrote:
>
> > JWarmUp recorded the class init order in pre-run to prevent runtime
> > unnecessary deoptimization due to class initialization out of order. Th=
e
>
> I don't understand that sentence sorry.
>
> Sorry, that is my mistake, it should be 'compilation failure'.
> > current design is wait for vm finished startup to startup warm up. We
> > have tried compile when class loading and found many problems so decide=
d
> > go with current design.
>
> I'm trying to understand the details of the current design and I'm
> afraid I'm not getting it at all. I would have expected the "pre-run" to
> generate a list of methods to compile, sorted by initialization order.
> So yes some tweaking to the runtime to track the initialization order.
>
> I would then expect the actual run to take that file and at some point
> during startup run through that list and load and initialize each class,
> then compile each method.
>
>
The methods remembered in order of time already in the file. In regular
compilation, all the classes in the compilation already resolved or can be
resolved. Since JWarmUp pre-compile those methods (in order as they are in
pre-run) at some point which is early than they were in pre-run, some
classes have not been loaded yet. We could not assume the class is loaded
by which class loader especially for custom class loaders, the compilation
has to fail. We supply an API for application to inform VM the time to
start warmup compilation. At that point, most classes have been loaded
already since application started, so most of the methods can be compiled
successfully though we may have a very small number of failures.
Application developers know the time point when to use this API to start
warmup compilation. Would this answer your question?
Thanks
Yumin
> David
> -----
>
> > You said it is like selective -Xcomp, yes, it looks like in first, bu=
t
> > next we will enhance with method profiling information to make more
> > optimized code.
> >
> > The changes have been made to many runtime files, so need comments
> > from runtime either.
> >
> > Thanks
> > Yumin
> >
> > On Fri, Apr 26, 2019 at 5:53 AM Kuai Wei <kuaiwei.kw@alibaba-inc.com
> > <mailto:kuaiwei.kw@alibaba-inc.com>> wrote:
> >
> > Hi David,
> >
> > I try to add more info about JWarmup. Yumin may explain more
> > detail later.
> >
> > In record phase, JWarmup will record hot methods and the class
> > initialize order. We believe class order is important. Without it,
> > most warmup compilation will be failed by deopt.
> >
> > In warmup phase, JVM will check init order before warmup
> > compilation. If the recorded dependent classes are initialized, (th=
e
> > classes may not be really dependent, we just check the init order),
> > the methods will be warmup compiled. So we delay warmup compilation
> > after JVM startup, we need wait JVM to load most classes.
> >
> > Thanks,
> > Kuai Wei
> >
> >
> ------------------------------------------------------------------
> > From:David Holmes <david.holmes@oracle.com
> > <mailto:david.holmes@oracle.com>>
> > Send Time:2019=E5=B9=B44=E6=9C=8826=E6=97=A5(=E6=98=9F=E6=9C=9F=
=E4=BA=94) 14:54
> > To:yumin qi <yumin.qi@gmail.com <mailto:yumin.qi@gmail.com>>;
> > hotspot-runtim. <hotspot-runtime-dev@openjdk.java.net
> > <mailto:hotspot-runtime-dev@openjdk.java.net>>
> > Cc:hotspot-dev <hotspot-dev@openjdk.java.net
> > <mailto:hotspot-dev@openjdk.java.net>>
> > Subject:Re: RFC: JWarmup precompile java hot methods at
> > application startup
> >
> > Hi Yumin,
> >
> > On 26/04/2019 2:07 am, yumin qi wrote:
> > > Hi,
> > >
> >
> > Apart from comments from compiler professionals can I have comments =
from
> > > runtime either? The changes mostly land in runtime area.
> >
> >
> I have to question why the changes mostly land in runtime area! The
> >
> high-level description of this feature does not sound like it depends on
> >
> >
> the runtime at all. The "recording" feature should just come from the
> >
> >
> JITs data; and the actual warmup should just be an interaction during VM
> >
> >
> initialization with the JIT. I don't see anything in the JEP to explain
> >
> > the actual design, and why it impacts on the runtime so much.
> >
> > It also sounds like a selective Xcomp mode to me.
> >
> >
> It even sounds very similar to Initialization-Time-Compilation (ITC)
> >
> > that we employed in Java Real-Time System:
> >
> >
> https://docs.oracle.com/javase/realtime/doc_2.2u1/release/JavaRTSCompilat=
ion.html
> >
> > Cheers,
> > David
> >
> > > Thanks
> > > Yumin
> > >
> > > On Tue, Apr 16, 2019 at 11:27 AM yumin qi <yumin.qi@gmail.co=
m
> > <mailto:yumin.qi@gmail.com>> wrote:
> > >
> > >> HI,
> > >>
> > >> Did anyone have comments for this version?
> > >>
> > >> Thanks
> > >> Yumin
> > >>
> > >> On Tue, Apr 9, 2019 at 10:36 AM yumin qi <yumin.qi@gmail.co=
m
> > <mailto:yumin.qi@gmail.com>> wrote:
> > >>
> > >>> Alan,
> > >>> Thanks! Updated in same link:
> > >>> http://cr.openjdk.java.net/~minqi/8220692/webrev-02/
> > >>>
> > >>> Removed non-boot loader branch in nativeLookup.cpp.
> >
> >>> Added jdk.jwarmup to boot loader list in make/common/Modules.gmk.
> > >>> Tested again to make sure the new changes.
> > >>>
> > >>> Thanks
> > >>> Yumin
> > >>>
> > >>>
> > >>> On Tue, Apr 9, 2019 at 4:48 AM Alan Bateman <
> Alan.Bateman@oracle.com <mailto:Alan.Bateman@oracle.com>>
> > >>> wrote:
> > >>>
> > >>>> On 09/04/2019 07:10, yumin qi wrote:
> > >>>>>
> >
> >>>>> Now the registerNatives is found when it looks up for native ent=
ry
> >
> >>>>> in lookupNative.cpp. I thought the class JWarmUp will be loaded by
> >
> >>>>> boot loader like Unsafe or WhiteBox, but I was wrong, it is loaded =
by
> >
> >>>>> app class loader so logic for obtaining its native entry put in bot=
h
> > >>>>> cases, boot loader and non boot loaders.
> > >>>>>
> >
> >>>> make/common/Modules.gmk is where BOOT_MODULES is defined with the li=
st
> > >>>> of modules mapped to the boot loader.
> > >>>>
> > >>>> -Alan
> > >>>>
> > >>>
> >
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic