This evaluation entry is from Tom Deneau @ AMD:
This webrev adds some logic to the jvmtiThreadState to cache a new
boolean flag, should_post_on_exceptions, which is true if reporting is
currently enabled on that thread for any of the following events
(throws, catches, method exit, frame pop).
Then, in the code generation for throws, if the capabilities for any
of these events are on, a runtime check of the new
should_post_on_exceptions flag is generated. Previously, we only
checked whether the capabilities for these events were enabled thru
jvmtiExport::can_post_on_exceptions(). The new logic allows us to
avoid an uncommon trap and deoptimization for cases where the
capabilities is enabled but the event reporting is not enabled, which
is the case when for example we have started with the jdwp agent but
not yet connected the debugger.
In addition, when the deoptimization does have to be performed, it is
done without using a global safepoint which makes it less costly.
All changes are platform-independent.
Numbers from a JIRA-based web workload. (JIRA makes fairly heavy use
of exception throws and catches). Here we compare the scores without
the jdwp agent to the scores with the agent installed but the debugger
not yet connected. Scores are relative to the no-jdwp-agent case.
40 Users 1 User
no jdwp agent 100% 100%
old hotspot, with jdwp agent 15% 30%
new hotspot, with jdwp agent 97% 87%