Re: RFC: JWarmup precompile java hot methods at application startup

[Kuai Wei]

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>
Send Time:2019年4月26日(星期五) 14:54
To:yumin qi <yumin.qi at gmail.com>; hotspot-runtim. <hotspot-runtime-dev at openjdk.java.net>
Cc:hotspot-dev <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> 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> 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>
>>> 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
>>>>
>>>