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

[Tobias Hartmann]

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 application
> on use scenario  and how we implement the interaction between application and scheduling (dispatch
> system, DS).
> 
> The load of each application is controlled by DS. The profiling data is collected against real
> input data (so it mostly matches the application run in production environments, thus reduce the
> deoptimization chance). When run with profiling data, application gets notification from DS when
> compiling should start, application then calls API to notify JVM the hot methods recorded in file
> can be compiled,  after the compilations, a message sent out to DS so DS will dispatch load into
> this application. 

Could you elaborate a bit more on how the communication between the DS and the application works? A
generic user application should not be aware of the pre-compilation, right? Let's assume I run a
little Hello World program, when/how is pre-compilation triggered?

Do I understand correctly that the profile information is only used for a "standalone" compilations
of a method or is it also used for inlining? For example, if we have profile information for method
B and method A inlines method B, does it use the profile information available for B when there is
no profile information available for A?

> A: During run with pre-compiled methods, deoptimization is only seen with null-check elimination so
> it is not eliminated. The profile data is not updated and re-used. That is, after deoptimized, it
> starts from interpreter mode like freshly loaded.

Why do you only see deoptimizations with null-check elimination? A pre-compiled method can still
have uncommon traps for reasons like an out of bounds array access or some loop predicate that does
not hold, right?

Thanks,
Tobias