Please, review a fix for:
https://bugs.openjdk.java.net/browse/JDK-8187289
Webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8187289-jvmti-framepop.1/
Summary:
The issue is that the FRAME_POP event request is not cleaned if
the requested
method frame is popped but the notification mode is temporarily
disabled.
If later the notification mode is enabled again then it will
post a FRAME_POP
event on the first return from an arbitrary method with the same
frame depth.
Notification mode for JVMTI_EVENT_FRAME_POP events is checked in
the
JvmtiExport::post_method_exit() under the condition:
if (state->is_enabled(JVMTI_EVENT_FRAME_POP)) {
Just removing this condition would likely to introduce a
performance regression
in interpreted mode. To mitigate it the fix introduces new
JVMTI_SUPPORT_FLAG
can_generate_frame_pop_events that is is checked instead of the
notification mode.
Also, it is necessary to to keep the
state->is_interp_only_mode() turned on
while the JvmtiEnvThreadState has any FRAME_POP requests
registered.
One alternate approach to this fix is to leave the current
behavior as it is
but update the JVMTI spec with some clarification about this
behavior.
Testing:
Verified with new unit test serviceability/jvmti/NotifyFramePop.
Also ran the nsk.jvmti, nsk.jdi and jtreg jdk_jdi tests to make
sure there is no regression.
Thanks,
Serguei
|
