RFC: JWarmup precompile java hot methods at application startup

[David Holmes]

On 27/04/2019 3:41 am, yumin qi wrote:
> David, Wei
>    Thanks for your comment.
>    Java RTS has an option -XX:PreInitList=my-preinit-file which stores 
> the pre-init class list. Will the classes in that list be initialized in 
> order?

Yes they would. That was its purpose.

>   JWarmUp recorded the class init order in pre-run to prevent runtime 
> unnecessary deoptimization due to class initialization out of order. The 

I don't understand that sentence sorry.

> current design is wait for vm finished startup to startup warm up. We 
> have tried compile when class loading and found many problems so decided 
> 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.

David
-----

>   You said it is like selective -Xcomp, yes, it looks like in first, but 
> 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 at alibaba-inc.com 
> <mailto:kuaiwei.kw at 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, (the
>     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 at oracle.com
>         <mailto:david.holmes at oracle.com>>
>         Send Time:2019年4月26日(星期五) 14:54
>         To:yumin qi <yumin.qi at gmail.com <mailto:yumin.qi at gmail.com>>;
>         hotspot-runtim. <hotspot-runtime-dev at openjdk.java.net
>         <mailto:hotspot-runtime-dev at openjdk.java.net>>
>         Cc:hotspot-dev <hotspot-dev at openjdk.java.net
>         <mailto:hotspot-dev at 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/JavaRTSCompilation.html
> 
>         Cheers,
>         David
> 
>          > Thanks
>          > Yumin
>          >
>          > On Tue, Apr 16, 2019 at 11:27 AM yumin qi <yumin.qi at gmail.com
>         <mailto:yumin.qi at 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 at gmail.com
>         <mailto:yumin.qi at 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 at oracle.com <mailto:Alan.Bateman at oracle.com>>
>          >>> wrote:
>          >>>
>          >>>> On 09/04/2019 07:10, yumin qi wrote:
>          >>>>>
>          >>>>>    Now the registerNatives is found when it looks up for native entry
>          >>>>> 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 both
>          >>>>> cases, boot loader and non boot loaders.
>          >>>>>
>          >>>> make/common/Modules.gmk is where BOOT_MODULES is defined with the list
>          >>>> of modules mapped to the boot loader.
>          >>>>
>          >>>> -Alan
>          >>>>
>          >>>
>