RFR: 8252593: [TESTBUG] serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java failed with JVMTI_ERROR_INVALID_SLOT

[Richard Reingruber]

On Sat, 12 Sep 2020 23:19:46 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> Continuing review [1] after transition to Git/Github.
> 
> I still cannot reproduce the issue.
> 
> RFC on alternatives:
> 
> 1. Integrate this change and ignore future JVMTI_ERROR_INVALID_SLOT
> 2. Don't ignore JVMTI_ERROR_INVALID_SLOT but integrate the rest of this patch. If the test still fails with
> JVMTI_ERROR_INVALID_SLOT we will at least know the depth of the frame. 3. Add trace code to VM_GetOrSetLocal in
> !PRODUCT or ASSERT configurations depending on an option or property.
> Any other ideas?
> 
> I'm in favour of 1.
> 
> [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-September/032876.html

Thanks @iignatev for providing the hint that helped finding the cause for the JVMTI_ERROR_INVALID_SLOT

https://bugs.openjdk.java.net/browse/JDK-8252593?focusedCommentId=14368599&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14368599

I would like to take a different approach now for fixing this by making sure the JVMTI GetLocalObject() call refers to
one of the recursiveMethod frames on stack.

How to do that? Can I close this PR and create a new branch JDK-8252593-2 and then a new PR?

-------------

PR: https://git.openjdk.java.net/jdk/pull/142