Bug ID: JDK-8276969 ciReplay: assert(is_loaded()) failed: must be loaded

Other
tbdUnresolved

Several replay files generated by following three java/lang/String tests crash with

#  Internal Error (/home/katya/work/JavaSE/Hotspot/ws/git/jdk.jdk.master/open/src/hotspot/share/ci/ciInstanceKlass.hpp:146), pid=29844, tid=29858
#  assert(is_loaded()) failed: must be loaded
#
# JRE version: Java(TM) SE Runtime Environment (18.0) (fastdebug build 18-internal+0-2021-11-10-1930227.katya...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 18-internal+0-2021-11-10-1930227.katya..., mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x8dd017]  ciMethod::find_monomorphic_target(ciInstanceKlass*, ciInstanceKlass*, ciInstanceKlass*, bool)+0x497


The list of tests:
 java/lang/String/StringJoinTest.java
 java/lang/String/Indent.java
 java/lang/String/CompactString/OffsetByCodePoints.java

The issue seems to be present only in latest jdk (jdk18) workspace, no crashes using latest jdk18 promoted builds
but it fails differently:

b18-b20:
 java.lang.NoClassDefFoundError: jdk/internal/reflect/MethodHandleAccessorFactory$LazyStaticHolder
 Error while parsing line 46: jdk/internal/reflect/MethodHandleAccessorFactory$LazyStaticHolder

b21:
 java.lang.NoClassDefFoundError: jdk/internal/reflect/MethodHandleAccessorFactory$LazyStaticHolder
 Error while parsing line 46 at position 80: jdk/internal/reflect/MethodHandleAccessorFactory$LazyStaticHolder

b22:
 Error while parsing line 425 at position 50: constant pool length mismatch: wrong class files?
 Failed on constant pool length mismatch: wrong class files?

> The tag mismatch error is in class java/util/stream/Stream. It's constant pool seems to be extended at runtime in a non-deterministic way. [~dlong], I was able to find the root cause and a reproducer for this. I added more information to JDK-8277301.
02-06-2023
The CI layer already keeps track of unloaded classes per accessing class, which is checked by ciEnv::check_get_unloaded_klass(). The missing piece is writing this unloaded classes information to the replay file (and reading it in at replay time). One way to do this might be to change the constant pool tag in the replay file to a special value that means "always treat as unresolved". Populating the unresolved classes list from JVM_CONSTANT_UnresolvedClass isn't quite right because the CI layer will try to look up the classes in the system dictionary.
20-10-2022
A quick summary of what we have discussed offline: A constant pool entry cannot just be treated as unresolved. The compiler does a “local” resolve but leaves the tag as unresolved. To replay compile that, the constant pool tags somehow need to be virtualized. But there are a lot of places which access the constant pool. So we either add a lot of hooks,or make a new ConstantPool subclass with virtual functions which is going to slow the whole JVM down. So, we are opting for the former solution with the idea to reroute all the accesses through a common place. An idea could be to introduce a new "ciConstantPool` abstraction. However, as this is more complex, we defer that to 19 for now.
18-11-2021
[~dlong] Argh, then my reasoning was wrong - sorry about that! IIRC I think I've checked all the usages and was convinced that everything is eventually routed through get_metadata(). That does not seem to be true.
18-11-2021
The class is on the whitelist, but the constant pool tag should still be replayed as unresolved.
18-11-2021
I was able to reproduce this. In my failure, we are compiling the static intializer for sun/invoke/util/Wrapper. Because -Xcomp is being used, the "new sun/invoke/util/Wrapper" instruction causes a trap because the constant pool slot for Wrapper hasn't been resolved. At replay time, the slot is resolve and we do get a warning: Warning: entry was unresolved in the replay data: sun/invoke/util/Wrapper but leave the tag as resolved, eventually leading to the assert when the replay compile tries to access the super class of Wrapper, which was never accessed in the captured compiled. [~chagedorn], this tag handling is a missing piece of 8262912 that you convinced me we didn't need, but now I don't remember why, and it seems we do need it after all :-)
18-11-2021
I got # Internal Error (/home/katya/work/JavaSE/Hotspot/ws/git/jdk.jdk.master/open/src/hotspot/share/ci/ciInstanceKlass.hpp:146), pid=17602, tid=17616 # assert(is_loaded()) failed: must be loaded # # V [libjvm.so+0x95c3b7] ciMethod::find_monomorphic_target(ciInstanceKlass, ciInstanceKlass, ciInstanceKlass*, bool)+0x497 when running one of replay files generated by jdk/lambda/ArrayCtorRefTest.java. No -Xcomp flag was used. Will provide instructions on how to reproduce the crash later.
18-11-2021
[~dlong], I still see these crashes but they are seen only when java/lang/Math/WorstCaseTests is run in -Xcomp mode (it is done by the test). To reproduce for example # Internal Error (/home/katya/work/JavaSE/Hotspot/ws/git/jdk.jdk.master/open/src/hotspot/share/ci/ciInstanceKlass.hpp:175), pid=26586, tid=26599 # assert(is_loaded()) failed: must be loaded # # Problematic frame: # V [libjvm.so+0x943318] ciInstanceKlass::compute_nonstatic_fields()+0x3f8 do: > $TESTED_JAVA/bin/javac -sourcepath open/test/jdk/java/lang/Math -d . open/test/jdk/java/lang/Math/WorstCaseTests.java > $TESTED_JAVA/bin/java -XX:ReplaySuppressInitializers=0 -XX:+ReplayCompiles -XX:ReplayDataFile=replay_bug8276969_WorstCaseTests_Xcomp.log
17-11-2021
After applying the proposed fixes for 8277316 and 8277310, I'm not seeing any more crashes.
17-11-2021
1683 void ciEnv::dump_replay_data(int compile_id) { 1684 static char buffer[O_BUFLEN]; Using a static buffer for the file name is not thread-safe, and seems to explain the corrupted replay files. I filed a new bug: JDK-8277316.
17-11-2021
The tag mismatch error is in class java/util/stream/Stream. It's constant pool seems to be extended at runtime in a non-deterministic way. According to javap, the length is 410, but at runtime it grows to 446. In the replay file, slot 428 contains a String, but when I try to replay it, that slot contains a Utf8. The extra slots are added by DefaultMethods::generate_default_methods().
17-11-2021
[~dlong] running "$TESTED_JDK/bin/java -XX:CompileCommand=option,::,DumpReplay -XX:ReplaySuppressInitializers=0 Indent " should generate dozens of replay files. In my case replaying 2 of them did lead to crash. " tag mismatch: wrong class files" is different failure and was mentioned in https://bugs.openjdk.java.net/browse/JDK-8277301
17-11-2021
[~epavlova] I don't get an error with your replay file, but if I create my own, I do get this error: Error while parsing line 9 at position 1077: tag mismatch: wrong class files? Is that the same error you are seeing?
17-11-2021
[~dlong], I am able to reproduce it. The original replay_bug8276969.log seems became obsolete, so I am attaching new one - replay_bug8276969_02.log. You can also try to generate replay files for Indent and then see if any of them is causing the crash. Here are the steps: > $TESTED_JDK/bin/javac open/test/jdk/java/lang/String/Indent.java > $TESTED_JDK/bin/java -XX:CompileCommand=option,::,DumpReplay -XX:ReplaySuppressInitializers=0 Indent > for i in `ls replay_pid*` > do > $TESTED_JDK/bin/java -XX:+ReplayCompiles -XX:ReplayDataFile=$i -XX:ReplaySuppressInitializers=0 > done Note, the crash happens with and without -XX:ReplaySuppressInitializers=0. I just use it to avoid other known failures.
17-11-2021
[~epavlova], I'm having trouble reproducing these after 8276095 was fixed. Can you still reproduce these failures?
16-11-2021
ILW = crash in compiler replay = MMH = P3
11-11-2021
All mentioned crashes are seen in b23. So the issue is introduced in b23.
11-11-2021
Similar crash received by running java/math/BigDecimal/DivideMcTests.java: # Internal Error (/home/katya/work/JavaSE/Hotspot/ws/git/jdk.jdk.master/open/src/hotspot/share/ci/ciInstanceKlass.hpp:175), pid=23999, tid=24012 # assert(is_loaded()) failed: must be loaded # # Problematic frame: # V [libjvm.so+0x8c4588] ciInstanceKlass::compute_nonstatic_fields()+0x3f8 To reproduce: > cp test/jdk/java/math/BigDecimal/DivideMcTests.java . > $TESTED_JDK/javac DivideMcTests.java > $TESTED_JDK/java -XX:+ReplayCompiles -XX:ReplayDataFile=replay_bug_DivideMcTests.log
11-11-2021
Another crash which seems to be related to this issue is: # Internal Error (/home/katya/work/JavaSE/Hotspot/ws/git/jdk.jdk.master/open/src/hotspot/share/ci/ciKlass.hpp:60), pid=31007, tid=31021 # assert(k != __null) failed: illegal use of unloaded klass # # JRE version: Java(TM) SE Runtime Environment (18.0) (fastdebug build 18-internal+0-2021-11-10-1930227.katya...) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 18-internal+0-2021-11-10-1930227.katya..., mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x8db8e0] ciMethod::ciMethod(methodHandle const&, ciInstanceKlass*)+0x10a0 I can reproduce it using replay files generated when running java/lang/String/SpecialCasingTest.java. No crash with latest promoted jdk18 builds. But it fails the same way as in case of " ciMethod::find_monomorphic_target" crash.
10-11-2021
The easiest way to reproduce the issue is to use test/jdk/java/lang/String/Indent.java. Just copy it somewhere, compile and run with attached replay file: > java -XX:+ReplayCompiles -XX:ReplayDataFile=replay_bug8276969.log
10-11-2021

Relates :	JDK-8332116 - Test compiler/ciReplay/TestServerVM.java failed: Unexpected exit code for positive case
Relates :	JDK-8277316 - ciReplay: dump_replay_data is not thread-safe