RFR (S): 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled

[serguei.spit...@oracle.com]

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