On Tue, 15 Sep 2020 13:34:21 GMT, Richard Reingruber <rr...@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
