RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant

[Reingruber, Richard]

Hi Serguei,

  > Two reviews has to be good enough unless anyone else did not want to 
  > review it as well.
  > I guess, it is good to push.

Ok. I'll wait a little longer and on Thursday I'll push it.

Thanks, Richard.

-----Original Message-----
From: serguei.spitsyn at oracle.com <serguei.spitsyn at oracle.com> 
Sent: Montag, 10. Februar 2020 19:11
To: Reingruber, Richard <richard.reingruber at sap.com>; Vladimir Ivanov <vladimir.x.ivanov at oracle.com>; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant

Hi Richard,

Thank you for the details on testing!
Two reviews has to be good enough unless anyone else did not want to 
review it as well.
I guess, it is good to push.

Thanks,
Serguei


On 2/10/20 03:26, Reingruber, Richard wrote:
> Hi Vladimir and Serguei,
>
> thanks for looking at the change!
>
>    > What exact tests do you run to verify the fix?
>
> The enhancement was tested running the JCK and JTREG tests which include many JVMTI, JDI and JDWP tests.
>
> To see if the tests cover this part of the JVMTI implementation I had removed the deoptimization of
> compiled frames on stack. I found that e.g. the following test covers this:
>
>    vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t012
>
> The test
>
>    vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002/hs202t002.java
>
> triggers the guarantee
>
>   238 void JvmtiThreadState::invalidate_cur_stack_depth() {
>   239   guarantee(SafepointSynchronize::is_at_safepoint() ||
>   240     (JavaThread *)Thread::current() == get_thread(),
>   241     "must be current thread or at safepoint");
>   242
>   243   _cur_stack_depth = UNKNOWN_STACK_DEPTH;
>   244 }
>   245
>
> because with the enhancement invalidate_cur_stack_depth() gets called by the VMThread executing the
> new handshake. So this is covered as well.
>
> Thanks again for reviewing.
>
> Do I need more reviews or are your reviews enough to push the enhancement?
>
> Best regards,
> Richard.
>
> -----Original Message-----
> From: serguei.spitsyn at oracle.com <serguei.spitsyn at oracle.com>
> Sent: Freitag, 7. Februar 2020 19:06
> To: Reingruber, Richard <richard.reingruber at sap.com>; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
>
> Hi Richard,
>
> It looks good to me.
> I can't comment on compiled methods non-entrancy.
>
> What exact tests do you run to verify the fix?
>
> Thanks,
> Serguei
>
>
> On 2/6/20 04:39, Reingruber, Richard wrote:
>> Hi,
>>
>> could I please get reviews for this small enhancement:
>>
>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/
>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8238585
>>
>> The change avoids making all compiled methods on stack not_entrant when switching a java thread to
>> interpreter only execution for jvmti purposes. It is sufficient to deoptimize the compiled frames on stack.
>>
>> Additionally a handshake is used instead of a vm operation to walk the stack and do the deoptimizations.
>>
>> Testing: JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms.
>>
>> Thanks, Richard.
>>
>> See also my question if anyone knows a reason for making the compiled methods not_entrant:
>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-January/030339.html