tobias.hartmann at oracle.com
Mon Jun 4 07:29:55 UTC 2018
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?
More information about the hotspot-dev