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

[Daniel D.Daugherty]

On Tue, 15 Sep 2020 13:34:21 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?

You can also change the PR back to draft, revamp the changes and then
change the PR back to "ready for review" or whatever it's called.
However, I don't know the preferred protocol for such things.

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

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