Digging through the history: The bug was incorrectly closed because this commit was linked to both JDK-8235385 and JDK-8287508:
https://github.com/openjdk/jdk8u-dev/commit/820ab134927cb76c61cf9c144637d18e0e2a4f2c
I think the right thing is therefore to close this one as Won't Fix.
21-06-2022
[~rcastanedalo] you're right, I didn't upload fixed version to Jira
https://github.com/apavlyutkin/jdk11u-dev/blob/8287508/test/hotspot/jtreg/compiler/unsafe/NonVolatileMemoryAccessWithLongOffset.java
21-06-2022
And we should also remove all the Review/Commit links that do not belong to this bug. If I understand correctly, only https://github.com/openjdk/jdk11u-dev/pull/1122 belongs here, right?
21-06-2022
I think we should just revert the state of this bug (including the title -> "The tests added to jdk-8 by 8235385 are to be ported to jdk-11") and open a new bug for whatever issues remain. In general, the clone feature should not be used.
21-06-2022
[~apavlyutkin] did you run the attached test (NonVolatileMemoryAccessWithLongOffset.java) on more recent JDK versions? It fails intermittently on JDK mainline (commit ad891461) with the following message:
java.lang.RuntimeException: maxValue does not match
at compiler.codegen.NonVolatileMemoryAccessWithLongOffset.fromBytes
at compiler.codegen.NonVolatileMemoryAccessWithLongOffset.main
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke
at java.base/java.lang.reflect.Method.invoke
at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run
at java.base/java.lang.Thread.run
21-06-2022
That was our mistake, we really should have raised new (test) enhancement, fix it in 11, and then backport to 8. But we just added new tests to 8235385->8u PR, thus the tests were added only to 8u. Then I cloned this one exactly to add absent tests to 11u, but somehow it was taken as a backport, that is why https://github.com/openjdk/jdk11u-dev/pull/1122 was labelled with 8235385 (because that was a backport) and this one went to Resolved state. The PR was in Review when we got known that 8235385 was not enough and LDR instructions must be patched too. So the alternatives were either to wait until tests finally got to 11 and then fix LDR, or just re-open this one with new intention
May be that would be better to close this one as Won't fix and clone new one without dirty history, just to make it transparent?
21-06-2022
Why was a clone and not a new (test) bug/enhancement used then? I think at least the commit/PR links from JDK-8235385 should be removed as they don't apply to this clone.
And if the tests have been ported, why was this re-opened?
21-06-2022
This is a clone of original JDK-8235385, and it wasn't resolved actually. Initially this one was cloned to port tests from 8 to 11 (they were forgotten in 11). That why it was in resolved state. The PR was not about the fix, only about backporting of tests from 8 to 11.
21-06-2022
Why was this re-opened? If the fix was incomplete, a new bug should be filed. Resolved issues should stay resolved.
21-06-2022
I'm confused. The PR and commit links seem to refer to JDK-8235385.
21-06-2022
Thus I raised new JDK-8288865. The test from JDK-8235385 will be added to 11u along with the delta required to reproduce LDR issue. Later only the delta will be backported to 8u. Is it Ok?
21-06-2022
A pull request was submitted for review.
URL: https://git.openjdk.java.net/jdk11u-dev/pull/1122
Date: 2022-06-01 07:21:28 +0000