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.spit...@oracle.com <serguei.spit...@oracle.com>
Sent: Freitag, 7. Februar 2020 19:06
To: Reingruber, Richard <richard.reingru...@sap.com>;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@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
