During testing of JDK-8278889 changes for JDK 18 next 3 tests failed on macosx-aarch64 (Apple_M1) in tier1 and tier3:

gc/stress/gcbasher/TestGCBasherWithG1.java
gc/stress/gcbasher/TestGCBasherWithSerial.java
gc/stress/gcbasher/TestGCBasherWithParallel.java

with:

java.lang.IllegalStateException
at gc.stress.gcbasher.ByteCursor.readUtf8(ByteCursor.java:110)
at gc.stress.gcbasher.Decompiler.decodeConstantPool(Decompiler.java:310)
at gc.stress.gcbasher.Decompiler.<init>(Decompiler.java:42)
at gc.stress.gcbasher.TestGCBasher.parseClassFiles(TestGCBasher.java:46)
at gc.stress.gcbasher.TestGCBasher.main(TestGCBasher.java:63)
at gc.stress.gcbasher.TestGCBasherWithSerial.main(TestGCBasherWithSerial.java:40)
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:833)

This failure is similar to JDK-8275316.

But when I re-did tier1, it passed. So it could not be related to JDK-8278889 changes.

I investigated it further and found that something strange happened with build. Running gcbasher tests standalone with JDK from failed tier1 build cause them immediately fail. But running with JDK from passed tier1 these tests never fail.

It looks like there is some difference in code/data layout of VM in these builds. But OS and clang versions were there same in both builds. I checked. It could be we have some uninitialized values or data stomp in these build.

I created this bug as place holder if people hit similar failure later.