Bug ID: JDK-8279317 compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java assumes immutable code

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 19
19 b14Fixed

compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java has been failing intermittently in the loom repo for the last few weeks. The typical output is:

----------System.err:(16/2068)----------
java.lang.RuntimeException: CompileCodeTestCase{executable=protected compiler.jvmci.compilerToVM.CompileCodeTestCase$Dummy(), bci=-1} : 3nd invocation returned different value from 2nd: expected   0x00007f41098d8360: 8984 2400 | a0fe ff55 | 4883 ec10 | 9090 9090 | 4181 7f1c | 0000 0000 | 0f84 0500  to equal   0x00007f41098d8360: 8984 2400 | a0fe ff55 | 4883 ec10 | 9090 9090 | 4181 7f1c | 0200 0000 | 0f84 0500 
	at jdk.test.lib.Asserts.fail(Asserts.java:594)
	at jdk.test.lib.Asserts.assertEquals(Asserts.java:205)
	at jdk.test.lib.Asserts.assertEQ(Asserts.java:178)
	at compiler.jvmci.compilerToVM.DisassembleCodeBlobTest.check(DisassembleCodeBlobTest.java:112)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
	at compiler.jvmci.compilerToVM.DisassembleCodeBlobTest.main(DisassembleCodeBlobTest.java:66)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:1496)

JavaTest Message: Test threw exception: java.lang.RuntimeException: CompileCodeTestCase{executable=protected compiler.jvmci.compilerToVM.CompileCodeTestCase$Dummy(), bci=-1} : 3nd invocation returned different value from 2nd: expected   0x00007f41098d8360: 8984 2400 | a0fe ff55 | 4883 ec10 | 9090 9090 | 4181 7f1c | 0000 0000 | 0f84 0500  to equal   0x00007f41098d8360: 8984 2400 | a0fe ff55 | 4883 ec10 | 9090 9090 | 4181 7f1c | 0200 0000 | 0f84 0500 
JavaTest Message: shutting down test

Changeset: 34d4ffce Author: Dean Long <dlong@openjdk.org> Date: 2022-03-15 07:24:50 +0000 URL: https://git.openjdk.java.net/jdk/commit/34d4ffcea5d71560c549655967de863342b48984
15-03-2022
MDash: https://mach5.us.oracle.com/mdash/jobs/dlong-8279317-20220312-1201-29974087 MDash: https://mach5.us.oracle.com/mdash/jobs/dlong-8279317-20220312-1202-29974099 MDash: https://mach5.us.oracle.com/mdash/jobs/dlong-8279317-20220312-1203-29974108 MDash: https://mach5.us.oracle.com/mdash/jobs/dlong-8279317-20220312-1204-29974119
12-03-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/7781 Date: 2022-03-11 04:14:00 +0000
11-03-2022
The test only runs with JVMCI, which means only with GCs that support JVMCI: UseSerialGC \|\| UseParallelGC \|\| UseG1GC. So technically, this test can't fail on jdk19, but the test is still broken in my opinion. I don't see the value in disassembling the same nmethod 3 times and comparing the results from the 2nd and 3rd times. It seems like even without nmethod entry barriers, any other change to the code would cause the test to fail, like an embedded oop moved after a GC, or a call site that gets updated.
11-03-2022
It looks like loom always has nmethod entry barriers enabled. So maybe this problem only exists in jdk19 with Shenandoah and ZGC?
08-03-2022
I think this is the nmethod entry barrier getting disarmed, which patches the code. If so, I don't see why this wouldn't affect jdk19 as well. [~eosterlund], do you agree?
08-03-2022