This looks reasonable to me.
The only question is about the quality of this testing.
How are we sure these errors are caused by races but not bugs in the GetLocalObject implementation?
Thanks,
Serguei
On 9/2/20 07:37, Reingruber, Richard wrote:
Hi,
please help review this fix for a TESTBUG in
serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java
Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8252593/webrev.0/
Bug: https://bugs.openjdk.java.net/browse/JDK-8252593
With this change the JVMTI test agent silently accepts JVMTI_ERROR_INVALID_SLOT
as result of a JVMTI GetLocalObject() call.
The target frame of the call varies because the target thread is running. In
rare cases it might not be one of the many frames of
GetLocalWithoutSuspendTest.recursiveMethod() as intended but the frame of a static
method without parameters which the target thread might call after returning from all
the recursive calls. This would result in JVMTI_ERROR_INVALID_SLOT.
Anyway JVMTI_ERROR_INVALID_SLOT has to be expected and should be silently
ignored.
Furthermore I have corrected the type of the parameter waitCycles of
Java_GetLocalWithoutSuspendTest_notifyAgentToGetLocal() to be jint. Now it
matches the declaration in GetLocalWithoutSuspendTest.java.
Thanks, Richard.
