Reply: JEP: https://bugs.openjdk.java.net/browse/JDK-8203832

[李三红(三红)]

Hi Tobias
Thanks for your questions,  see my inline comments
Thanks
Sanhon
-----------------------------------------------------------------
Sender:Tobias Hartmann <tobias.hartmann at oracle.com
Sent at:2018 Jun 4 (Mon) 15:2
Recipient:yumin qi <yumin.qi at gmail.com
Cc:hotspot-dev <hotspot-dev at openjdk.java.net
Subject:Re: JEP: https://bugs.openjdk.java.net/browse/JDK-820383
Hi Yumin
thanks for the details
On 01.06.2018 05:01, yumin qi wrote
> Thanks for your review/questions. First I would introduce some background
> of JWarmup applicatio
> on use scenario  and how we implement the interaction between application
> and scheduling (dispatc
> system, DS)

> The load of each application is controlled by DS. The profiling data is
> collected against rea
> input data (so it mostly matches the application run in production
> environments, thus reduce th
> deoptimization chance). When run with profiling data, application gets
> notification from DS whe
> compiling should start, application then calls API to notify JVM the hot
> methods recorded in fil
> can be compiled,  after the compilations, a message sent out to DS so DS
> will dispatch load int
> this application
Could you elaborate a bit more on how the communication between the DS and
the application works? 
generic user application should not be aware of the pre-compilation, right?
Let's assume I run 
little Hello World program, when/how is pre-compilation triggered
The user application will use API to tell JWarmup to kickoff pre-compilation at some appropriate point, generally after  app initialization done,  the basic workflow as follows
-- DS freezes incoming user requests
-- App does the necessary initialization
-- After the initialization is done.
----> Notify JWarmup to kickoff pre-compilation(via API)
****** JWarmup does the compilation wor
<---- The app gets notified after the compilation is done(via API in polling way
-- DS resumes the requests, the application now is ready for service
This is case how we use JWarmup, but we do believe the above process cloud be generalized and any app running inside cloud datacenter could benefit from the model by integrating java compilation with DS
By this way, the java platform provides flexible mechanism for cloud scheduling system to define compilation behavior according to load time
Do I understand correctly that the profile information is only used for a
"standalone" compilation
of a method or is it also used for inlining? For example, if we have profile
information for metho
B and method A inlines method B, does it use the profile information
available for B when there i
no profile information available for A
It does support inlining. 
Actually, in "recording" phase, JWarmup also records the "MethodData" information,  which can be used for compilation in next run
> A: During run with pre-compiled methods, deoptimization is only seen with
> null-check elimination s
> it is not eliminated. The profile data is not updated and re-used. That
> is, after deoptimized, i
> starts from interpreter mode like freshly loaded
Why do you only see deoptimizations with null-check elimination? A
pre-compiled method can stil
have uncommon traps for reasons like an out of bounds array access or some
loop predicate that doe
not hold, right
We saw null-check elimination caused the de-optimization in our most cases, that's the reason this has been disabled by default in JWarmup
But you are correct, assumption might be made wrong in some other cases, that's the reason JWarmup provides the option to user to deoptimize the pre-compiled methods after peak load via
-XX:CompilationWarmUpDeoptTime control flag, which allows user to choose a time roughly after the peak time to do the deoptimization
Thanks
Tobia