JDK-8331194 : NPE in ArrayCreationTree.java with -XX:-UseCompressedOops
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 23,24
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • CPU: x86,aarch64
  • Submitted: 2024-04-26
  • Updated: 2024-07-29
  • Resolved: 2024-07-16
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 23 JDK 24
23Fixed 24 b07Fixed
Related Reports
Relates :  
JDK-8316991 - Reduce nullable allocation merges
Description
ArrayCreationTree.java fails intermittently with the following exception when the JVM is configured with -XX:-UseCompressedOops (only seen on Linux Aarch64 so far):

An exception has occurred in the compiler (23-ea). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
java.lang.NullPointerException: Cannot read field "head" because "this.elems" is null
	at jdk.compiler/com.sun.tools.javac.util.ListBuffer.first(ListBuffer.java:190)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.merge(JavacParser.java:1270)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.foldIfNeeded(JavacParser.java:1254)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.foldStrings(JavacParser.java:1232)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.term2Rest(JavacParser.java:1208)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.term2(JavacParser.java:1122)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.term1(JavacParser.java:1090)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:1046)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:1026)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.parseExpression(JavacParser.java:891)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.arguments(JavacParser.java:2249)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.classCreatorRest(JavacParser.java:2699)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.creator(JavacParser.java:2594)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.term3(JavacParser.java:1439)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.term2(JavacParser.java:1119)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.term1(JavacParser.java:1090)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:1046)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:1026)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.parseExpression(JavacParser.java:891)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.parseSimpleStatement(JavacParser.java:3098)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.blockStatement(JavacParser.java:2847)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.blockStatements(JavacParser.java:2784)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.block(JavacParser.java:2754)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.block(JavacParser.java:2768)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.parseSimpleStatement(JavacParser.java:2998)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.blockStatement(JavacParser.java:2847)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.parseStatementAsBlock(JavacParser.java:2809)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.parseSimpleStatement(JavacParser.java:3002)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.blockStatement(JavacParser.java:2847)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.blockStatements(JavacParser.java:2784)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.block(JavacParser.java:2754)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.block(JavacParser.java:2768)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.methodDeclaratorRest(JavacParser.java:4936)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.constructorOrMethodOrFieldDeclaration(JavacParser.java:4733)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.classOrInterfaceOrRecordBodyDeclaration(JavacParser.java:4658)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.classInterfaceOrRecordBody(JavacParser.java:4597)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.classDeclaration(JavacParser.java:4297)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.classOrRecordOrInterfaceOrEnumDeclaration(JavacParser.java:4244)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.classOrInterfaceOrRecordBodyDeclaration(JavacParser.java:4647)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.classInterfaceOrRecordBody(JavacParser.java:4597)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.classDeclaration(JavacParser.java:4297)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.classOrRecordOrInterfaceOrEnumDeclaration(JavacParser.java:4244)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.typeDeclaration(JavacParser.java:4233)
	at jdk.compiler/com.sun.tools.javac.parser.JavacParser.parseCompilationUnit(JavacParser.java:4040)
	at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:653)
	at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:630)
	at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:690)
	at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:1041)
	at jdk.compiler/com.sun.tools.javac.main.JavaCompiler$InitialFileParser.parse(JavaCompiler.java:1984)
	at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:1028)
	at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.parseInternal(JavacTaskImpl.java:258)
	at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.invocationHelper(JavacTaskImpl.java:152)
	at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.parse(JavacTaskImpl.java:248)
	at ArrayCreationTree.main(ArrayCreationTree.java:60)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1575)
Comments
A pull request was submitted for review. Branch: jdk23 URL: https://git.openjdk.org/jdk/pull/20210 Date: 2024-07-17 05:18:16 +0000
17-07-2024
Changeset: 005fb67e Branch: master Author: Cesar Soares Lucas <cslucas@openjdk.org> Committer: Vladimir Kozlov <kvn@openjdk.org> Date: 2024-07-16 20:47:42 +0000 URL: https://git.openjdk.org/jdk/commit/005fb67e99370ef2bd15dae621a3924e1cf00124
16-07-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/20087 Date: 2024-07-09 00:06:33 +0000
09-07-2024
That's great news, thanks for the update. Enjoy your vacation!
05-07-2024
Hi, again, [~thartmann]. I just wanted to let you know that I've found the cause of the issue and I've a fix for it, the patch is quite small. I'm going to create a PR for it once I return from holidays. > But doesn't above deopt log prove that the problem is incorrect debug info that has elems = null? Yes, I definitely agree with you here. What confused me was the not seeing any trace message from RAM.
04-07-2024
Thanks for the updates, [~cslucas]. But doesn't above deopt log prove that the problem is incorrect debug info that has elems = null? - private 'elems' 'Lcom/sun/tools/javac/util/List;' @24 null (0x0000000000000000) I checked the history and I was able to reproduce this with -XX:-TieredCompilation, so C1 is not involved. I also verified that it still happens with -XX:-OptimizeUnstableIf.
28-06-2024
Just another quick update: I still don't know what's the root cause of the problem. I'm still not able to reproduce the problem with RAM disabled, which makes me thing RAM is somehow related to the issue. However, in a JVM modified to print the compilation-id and compilation-level of every method on a stack trace, some failures show that the top 4 methods on the stack were actually compiled by C1...?!
26-06-2024
> Yes, that explanation makes perfect sense and is usually the reason for why an issue only reproduces if multiple test are executed. The agentvm mode will lead to multiple tests being executed in the same JVM instance and therefore lead to different warmup/profiling/inlining/compilation of "shared" methods. Yeah, I realized this could explain the "missing" trace messages after I noted that the test is configured with agentvm. > UPDATE: There are .trace files, in my case in ./test-support/jtreg_open_test_langtools_tier1/jtData/agentServer.5.trace, that keep track of the order. Thanks! Finding which tests executed in the same agent was exactly what I planned for next step.
10-06-2024
[~cslucas] Yes, that explanation makes perfect sense and is usually the reason for why an issue only reproduces if multiple test are executed. The agentvm mode will lead to multiple tests being executed in the same JVM instance and therefore lead to different warmup/profiling/inlining/compilation of "shared" methods. See also: https://openjdk.org/jtreg/faq.html#what-are-the-agentvm-and-othervm-modes What I did in the past was to print the sequence of test executions per VM and then try to reproduce the issue by enforcing that same sequence manually. Unfortunately, that was a few years ago and I don't recall how to retrieve the order of test executions on a specific VM. I'll check with our jtreg experts. UPDATE: There are .trace files, in my case in ./test-support/jtreg_open_test_langtools_tier1/jtData/agentServer.5.trace, that keep track of the order.
10-06-2024
Thank you for the replay file [~thartmann]. Here is an update on the issue: these other two tests are failing with the same issue: ArrayPositionConsistency and SourceDocTreeScannerTest I've an hypothesis to explain why I don't see any RAM trace in the failing test log but if we disable RAM we don't see any failure. The failing tests are configured to run on 'agentvm' which means that JTREG may reuse an existing VM to run the test. I think the `foldStrings` method is being compiled during execution of one test and then being reused to execute other tests. I'm not familiar with JTREG internals, does this reasoning makes sense to you? If that is possible, it would explain why there is no RAM trace in the failing test log and also why the issue doesn't reproduce when executing the test directly.
07-06-2024
I tried to dump a replay file with -XX:CompileCommand=dumpreplay,com.sun.tools.javac.parser.JavacParser::term2Rest but for some reason, I don't get one in the failing cases. I attached one from a non-failing case though (replay_pid447904_compid8704.log), maybe it's helpful.
07-06-2024
Regarding JDK-8322854 being the problem: That might well be but the issue does at least not reproduce before JDK-8316991 for me.
04-06-2024
[~cslucas] Thanks for the update! Let me know if you want me to run some testing. I can run in parallel on multiple machines and it therefore reproduces quickly.
04-06-2024
> The failure happened with a 64-bit binary (in fact, we don't test 32-bit at all). Just curious, why did you test with a 32-bit binary? I was testing with a 32-bit binary because I saw one occurrence of this failure in a Linux x86 GHA build. > That never worked for me. Yeah, I executed like this thousands of times and didn't see the failure even once. Testing the whole group I do get about 1 failure in <50 executions. Unfortunately, each execution takes about 15 minutes for me. Thank you for sharing the Deopt information. I didn't find the root of the problem yet, it's still very elusive to reproduce. Here is the piece of the puzzle that I'm currently dealing with: - I didn't see any occurrence of the issue when "ReduceAllocationMerges" is disabled. _However_, I don't see any debug message printed during RAM optimization when the error does happen! I.e., it looks like the problem isn't directly related to the RAM transformation. I did this test on a modified release build that prints debug info to tty. I'm wondering if this change may actually be the problem: https://github.com/openjdk/jdk/commit/7cd25ed605469e3946a204b7b18d975c9768f2df
03-06-2024
> I was finally able to reproduce it on Mac M1! Great! Linux AArch64 seems to be much more intermittent. Linux x64 does not work for me. It's most likely just bad luck (timing / scheduling differences) though.
30-05-2024
> both running a 32bit binary The failure happened with a 64-bit binary (in fact, we don't test 32-bit at all). Just curious, why did you test with a 32-bit binary? > I tested mostly running directly the failing test `ArrayCreationTree.java` That never worked for me. > Do you think it makes a difference running the whole test group and running only the failing test? Yes, it does and it's been the same with many intermittent failures in the past. It's mostly about different warmup / profiling that needs to happen and is triggered by other tests. Here's some more information, printing the rematerialized object(s): UNCOMMON TRAP method=com.sun.tools.javac.parser.JavacParser.merge(Lcom/sun/tools/javac/util/ListBuffer;Lcom/sun/tools/javac/util/ListBuffer;)Z bci=14 pc=0x000000010fb5e7ac, relative_pc=0x00000000000006ac, debug_id=0 compiler=c2 compile_id=9010 (@0x000000010fb5e7ac) thread=36403 reason=unstable_if action=reinterpret unloaded_class_index=-1 debug_id=0 REALLOC OBJECTS in thread 0x0000000128c2be00 object <0x00000002980a60d0> of type 'com/sun/tools/javac/util/ListBuffer' allocated (40 bytes) com.sun.tools.javac.util.ListBuffer {0x00000002980a60d0} - klass: 'com/sun/tools/javac/util/ListBuffer' - ---- fields (total size 5 words): - private 'count' 'I' @12 0 (0x00000000) - private 'shared' 'Z' @16 false (0x00) - private 'elems' 'Lcom/sun/tools/javac/util/List;' @24 a 'com/sun/tools/javac/util/List$1'{0x000000028173a8a8} (0x000000028173a8a8) - private 'last' 'Lcom/sun/tools/javac/util/List;' @32 null (0x0000000000000000) object <0x00000002980a60f8> of type 'com/sun/tools/javac/util/ListBuffer' allocated (40 bytes) com.sun.tools.javac.util.ListBuffer {0x00000002980a60f8} - klass: 'com/sun/tools/javac/util/ListBuffer' - ---- fields (total size 5 words): - private 'count' 'I' @12 6 (0x00000006) - private 'shared' 'Z' @16 false (0x00) - private 'elems' 'Lcom/sun/tools/javac/util/List;' @24 null (0x0000000000000000) - private 'last' 'Lcom/sun/tools/javac/util/List;' @32 a 'com/sun/tools/javac/util/List'{0x00000002980a6030} (0x00000002980a6030) DEOPT PACKING thread=0x0000000128c2be00 vframeArray=0x000000012bb62e00 Compiled frame (sp=0x000000016d3f9b90 unextended sp=0x000000016d3f9b90, fp=0x00000000ffffffff, real_fp=0x000000016d3f9c10, pc=0x000000010fb5e7ac) Virtual frames (innermost/newest first): VFrame 0 (0x000000011e046410) - com.sun.tools.javac.parser.JavacParser.merge(Lcom/sun/tools/javac/util/ListBuffer;Lcom/sun/tools/javac/util/ListBuffer;)Z - if_icmpne @ bci=14 VFrame 1 (0x000000011e046e90) - com.sun.tools.javac.parser.JavacParser.foldIfNeeded(Lcom/sun/tools/javac/tree/JCTree$JCExpression;Lcom/sun/tools/javac/util/ListBuffer;Lcom/sun/tools/javac/util/ListBuffer;Z)Z - invokevirtual @ bci=27 VFrame 2 (0x000000011e047618) - com.sun.tools.javac.parser.JavacParser.foldStrings(Lcom/sun/tools/javac/tree/JCTree$JCExpression;)Lcom/sun/tools/javac/tree/JCTree$JCExpression; - invokevirtual @ bci=84 VFrame 3 (0x000000011e047da0) - com.sun.tools.javac.parser.JavacParser.term2Rest(Lcom/sun/tools/javac/tree/JCTree$JCExpression;I)Lcom/sun/tools/javac/tree/JCTree$JCExpression; - invokevirtual @ bci=486 DEOPT UNPACKING thread=0x0000000128c2be00 vframeArray=0x000000012bb62e00 mode=2 Virtual frames (outermost/oldest first): VFrame 3 (0x000000012bb63698) - com.sun.tools.javac.parser.JavacParser.term2Rest(Lcom/sun/tools/javac/tree/JCTree$JCExpression;I)Lcom/sun/tools/javac/tree/JCTree$JCExpression; - invokevirtual @ bci=486 sp=0x000000016d3f9ae0 VFrame 2 (0x000000012bb63630) - com.sun.tools.javac.parser.JavacParser.foldStrings(Lcom/sun/tools/javac/tree/JCTree$JCExpression;)Lcom/sun/tools/javac/tree/JCTree$JCExpression; - invokevirtual @ bci=84 sp=0x000000016d3f9a40 VFrame 1 (0x000000012bb635c8) - com.sun.tools.javac.parser.JavacParser.foldIfNeeded(Lcom/sun/tools/javac/tree/JCTree$JCExpression;Lcom/sun/tools/javac/util/ListBuffer;Lcom/sun/tools/javac/util/ListBuffer;Z)Z - invokevirtual @ bci=27 sp=0x000000016d3f99c0 VFrame 0 (0x000000012bb63560) - com.sun.tools.javac.parser.JavacParser.merge(Lcom/sun/tools/javac/util/ListBuffer;Lcom/sun/tools/javac/util/ListBuffer;)Z - if_icmpne @ bci=14 sp=0x000000016d3f9930
30-05-2024
I was finally able to reproduce it on Mac M1!
30-05-2024
[~thartmann] I tested on Linux AArch64 and Linux x86_64 - both running a 32bit binary and always with -UseCompressedOops. I tested mostly running directly the failing test `ArrayCreationTree.java` but I also tried a few times running the whole test group. Do you think it makes a difference running the whole test group and running only the failing test? I'm running now on Mac M1 and I'll see if I can reproduce it. My observations agree with yours, there is something wrong happening when I reduce the merge involving `listBuf` that is causing setting the `elems` field of the object to NULL. I did create a test with a "mock-up" of `foldStrings->foldIfNeeded->merge` but no luck reproducing the issue.
29-05-2024
From looking at the relevant code, it seems that the problem is that accessing litBuf.first() fails because some field is null. The litBuf = new ListBuffer<>() object is created in JavacParser::foldStrings. I assume it's scalar replaced and something went wrong. Maybe one could try to extract a standalone test from that code.
29-05-2024
[~cslucas] on which platforms/configuration did you try to reproduce? It still reproduces for me on Apple M1, Mac_OS_X_14.2 and AArch64 with Oracle Linux. But only with product builds and only when running all of open/test/langtools/:tier1 with -XX:-UseCompressedOops. I tried a few things as well but wasn't able to improve reproducibility.
29-05-2024
I reproduced with -XX:+TraceDeoptimization and the output is consistent with my hypothesis that scalar replacement of ListBuffer is the issue: UNCOMMON TRAP method=com.sun.tools.javac.parser.JavacParser.merge(Lcom/sun/tools/javac/util/ListBuffer;Lcom/sun/tools/javac/util/ListBuffer;)Z bci=14 pc=0x0000ffff79302424, relative_pc=0x00000000000006e4, debug_id=0 compiler=c2 compile_id=9058 (@0x0000ffff79302424) thread=3948942 reason=unstable_if action=reinterpret unloaded_class_index=-1 debug_id=0 REALLOC OBJECTS in thread 0x0000ffff8456e870 object <0x0000ffff57fbfba8> of type 'com/sun/tools/javac/util/ListBuffer' allocated (40 bytes) object <0x0000ffff57fbfbd0> of type 'com/sun/tools/javac/util/ListBuffer' allocated (40 bytes) DEOPT PACKING thread=0x0000ffff8456e870 vframeArray=0x0000fffe848d2b00 Compiled frame (sp=0x0000fffeffdfdb90 unextended sp=0x0000fffeffdfdb90, fp=0x00000000ffffffff, real_fp=0x0000fffeffdfdc10, pc=0x0000ffff79302424) Virtual frames (innermost/newest first): VFrame 0 (0x0000ffff086887e0) - com.sun.tools.javac.parser.JavacParser.merge(Lcom/sun/tools/javac/util/ListBuffer;Lcom/sun/tools/javac/util/ListBuffer;)Z - if_icmpne @ bci=14 VFrame 1 (0x0000ffff08689260) - com.sun.tools.javac.parser.JavacParser.foldIfNeeded(Lcom/sun/tools/javac/tree/JCTree$JCExpression;Lcom/sun/tools/javac/util/ListBuffer;Lcom/sun/tools/javac/util/ListBuffer;Z)Z - invokevirtual @ bci=27 VFrame 2 (0x0000ffff086899e8) - com.sun.tools.javac.parser.JavacParser.foldStrings(Lcom/sun/tools/javac/tree/JCTree$JCExpression;)Lcom/sun/tools/javac/tree/JCTree$JCExpression; - invokevirtual @ bci=84 VFrame 3 (0x0000ffff0868a170) - com.sun.tools.javac.parser.JavacParser.term2Rest(Lcom/sun/tools/javac/tree/JCTree$JCExpression;I)Lcom/sun/tools/javac/tree/JCTree$JCExpression; - invokevirtual @ bci=486 DEOPT UNPACKING thread=0x0000ffff8456e870 vframeArray=0x0000fffe848d2b00 mode=2 Virtual frames (outermost/oldest first): VFrame 3 (0x0000fffe848d3398) - com.sun.tools.javac.parser.JavacParser.term2Rest(Lcom/sun/tools/javac/tree/JCTree$JCExpression;I)Lcom/sun/tools/javac/tree/JCTree$JCExpression; - invokevirtual @ bci=486 sp=0x0000fffeffdfdae0 VFrame 2 (0x0000fffe848d3330) - com.sun.tools.javac.parser.JavacParser.foldStrings(Lcom/sun/tools/javac/tree/JCTree$JCExpression;)Lcom/sun/tools/javac/tree/JCTree$JCExpression; - invokevirtual @ bci=84 sp=0x0000fffeffdfda40 VFrame 1 (0x0000fffe848d32c8) - com.sun.tools.javac.parser.JavacParser.foldIfNeeded(Lcom/sun/tools/javac/tree/JCTree$JCExpression;Lcom/sun/tools/javac/util/ListBuffer;Lcom/sun/tools/javac/util/ListBuffer;Z)Z - invokevirtual @ bci=27 sp=0x0000fffeffdfd9c0 VFrame 0 (0x0000fffe848d3260) - com.sun.tools.javac.parser.JavacParser.merge(Lcom/sun/tools/javac/util/ListBuffer;Lcom/sun/tools/javac/util/ListBuffer;)Z - if_icmpne @ bci=14 sp=0x0000fffeffdfd930 UNCOMMON TRAP method=com.sun.tools.javac.util.ListBuffer.first()Ljava/lang/Object; bci=4 pc=0x0000ffff78ed25ec, relative_pc=0x000000000000006c, debug_id=0 compiler=c2 compile_id=9035 (@0x0000ffff78ed25ec) thread=3948942 reason=null_check action=maybe_recompile unloaded_class_index=-1 debug_id=0 DEOPT PACKING thread=0x0000ffff8456e870 vframeArray=0x0000fffe840105e0 Compiled frame (sp=0x0000fffeffdfd900 unextended sp=0x0000fffeffdfd900, fp=0x0000fffeffdfd9b0, real_fp=0x0000fffeffdfd920, pc=0x0000ffff78ed25ec) Virtual frames (innermost/newest first): VFrame 0 (0x0000ffff086887e0) - com.sun.tools.javac.util.ListBuffer.first()Ljava/lang/Object; - fast_agetfield @ bci=4 DEOPT UNPACKING thread=0x0000ffff8456e870 vframeArray=0x0000fffe840105e0 mode=2 Virtual frames (outermost/oldest first): VFrame 0 (0x0000fffe84010d40) - com.sun.tools.javac.util.ListBuffer.first()Ljava/lang/Object; - fast_agetfield @ bci=4 sp=0x0000fffeffdfd8b0
29-05-2024
Just a quick update: No luck so far in reproducing this. I've tried a few different ways and run a few thousand times but so far nothing.
28-05-2024
Thanks for assigning [~thartmann]. I'm looking into it.
22-05-2024
[~cslucas] please have a look. Unfortunately, this is very hard to reproduce. You need to run open/test/langtools/:tier1 with -XX:-UseCompressedOops with a release build on AArch64 and it reproduces ~ 1/50.
22-05-2024
I narrowed this down to jdk-23+18-1426 which only has one change: JDK-8316991 The issue still reproduces with latest jdk-23+24-1975 from 2024-05-22 01:25 UTC which has all the fixes of other relevant regressions from JDK-8316991. The issue does not reproduce anymore with XX:+UnlockDiagnosticVMOptions -XX:-ReduceAllocationMerges. Updated ILW = Incorrect result with C2 compiled code, reproducible but intermittent with javac, XX:+UnlockDiagnosticVMOptions -XX:-ReduceAllocationMerges = HMM = P2
22-05-2024
Initial ILW = Intermittent null pointer exception with C2 enabled, single test and intermittent, use -XX:+UseCompressedOops = HLM = P3
29-04-2024
To summarize the initial findings by testing different combinations: the test fails only without compressed OOPs (which suggests it may be a JVM bug), fails for all GCs (which suggests it is *not* a GC bug), and seems to fail only when C2 is enabled (which suggests it may be a compiler bug, even thought it could also be that disabling C2 affects the timing of the test execution, since this seems to be a time-sensitive failure). Moving to hotspot/compiler for initial triaging.
26-04-2024
Assigned to tools/javac for initial triaging, but it could be a JVM issue since the failure is only seen when using -XX:-UseCompressedOops. Feel free to redirect.
26-04-2024