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.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
