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

[Reingruber, Richard]

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