On Sat, 12 Sep 2020 23:19:46 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? ------------- PR: https://git.openjdk.java.net/jdk/pull/142
