Bug ID: JDK-8236042 [TESTBUG] serviceability/sa/ClhsdbCDSCore.java fails with -Xcomp -XX:TieredStopAtLevel=1

JDK 11	JDK 15	JDK 16
11.0.14Fixed	15-poolUnresolved	16 b07Fixed

Fix Request (11u) Backport for parity with Oracle 11.0.15. The original patch does not apply cleanly due to context difference. However, that patch is small, can be applied manually. The 11u patch has been reviewed.
24-11-2021
URL: https://hg.openjdk.java.net/jdk/jdk/rev/e19f8954f91e User: poonam Date: 2020-07-19 22:40:04 +0000
19-07-2020
Comments from Vladimir on review mailing list, I think next are reasons you don't get MDO in this scenario. Tier1 (C1 compilation) does not generate profiling code and does not created MDO. C1 request MDO only with tiers 2 and 3 [1][2]. With -Xcomp flag a Java method is not executed in Interpreter but requests its compilation and waits when it is finished. As result MDO is not created in Interpreter too. May be late if a method is deoptimized it will be executed in Interpreter and MDO will be created. Thanks, Vladimir [1] http://hg.openjdk.java.net/jdk/jdk/file/796c9fa50850/src/hotspot/share/c1/c1_Compilation.hpp#l226 [2] http://hg.openjdk.java.net/jdk/jdk/file/796c9fa50850/src/hotspot/share/c1/c1_Compilation.cpp#l381
11-07-2020
Thanks Chris for the quick suggestion, yes that's good idea. Will get that done. Thanks,
07-07-2020
Is there a reason you are using contains() rather than equals()? Rather than a loop you could convert to a collection and then just do: if (testJavaOpts.contains("-Xcomp") && testJavaOpts.contains("-XX:TieredStopAtLevel=1"))
06-07-2020
Thanks Chris for the clarification. I think best way is to modify the test to handle the scenario of "-Xcomp -XX:TieredStopAtLevel=1" == diff -r a7bf4902b7cf test/hotspot/jtreg/serviceability/sa/ClhsdbCDSCore.java --- a/test/hotspot/jtreg/serviceability/sa/ClhsdbCDSCore.java Mon Jun 29 15:03:36 2020 -0700 +++ b/test/hotspot/jtreg/serviceability/sa/ClhsdbCDSCore.java Sat Jul 04 08:43:34 2020 +0000 @@ -57,6 +57,7 @@ import jdk.test.lib.process.OutputAnalyzer; import jdk.test.lib.process.ProcessTools; import jdk.test.lib.SA.SATestUtils; +import jdk.test.lib.Utils; import jtreg.SkippedException; @@ -168,9 +169,25 @@ cleanup(); throw new SkippedException("The CDS archive is not mapped"); } - - cmds = List.of("printmdo -a", "printall", "jstack -v"); - + String[] testJavaOpts = Utils.getTestJavaOpts(); + boolean xcom = false; + int tieredlevel = 0; + for(int i=0; i<testJavaOpts.length; i++) { + if(testJavaOpts[i].contains("-Xcomp")) { + xcom = true; + } + if(testJavaOpts[i].contains("-XX:TieredStopAtLevel=1")) { + tieredlevel = 1; + } + } + if(xcom && tieredlevel == 1) { + // No MDOs are allocated in -XX:TieredStopAtLevel=1 + -Xcomp mode + // The reason is methods being compiled aren’t hot enough + // Let's not call printmdo in such scenario + cmds = List.of("printall", "jstack -v"); + } else { + cmds = List.of("printmdo -a", "printall", "jstack -v"); + } Map<String, List<String>> expStrMap = new HashMap<>(); Map<String, List<String>> unExpStrMap = new HashMap<>(); expStrMap.put("printmdo -a", List.of(
04-07-2020
[~fmatte]I think you're asking how does a method ever get hot enough to create an mdo when compiling with -Xcomp. I think it's because the method is still profiled unless you are using XX:TieredStopAtLevel > = 3. Profiling isn't just done by the interpreter, and -Xcomp does not prevent tiered compilation.
02-07-2020
I looked this issue sometime back. yes in -XX:TieredStopAtLevel=1 + -Xcomp we don't get any data from printmdo. The thing which surprised me is we get some output from Printmdo, when we run test with -XX:TieredStopAtLevel=1 and -Xcomp individually.
02-07-2020
So it looks like we need to find a way to either not run the test with "-Xcomp -XX:TieredStopAtLevel=1", or at least modify the test to realize it won't get any printmdo output while in that mode.
02-07-2020
From Vladimir Ivanov: I tried 2 configs: $ ...slowdebug/images/jdk/bin/java -XX:+PrintMethodData -XX:+Verbose -XX:TieredStopAtLevel=1 EmptyMain build_interpreter_method_data for virtual jobject java.util.ImmutableCollections$SetN$SetNIterator.next() build_interpreter_method_data for static jobject java.util.concurrent.ConcurrentHashMap.tabAt(jobject, jint) ... $ ...slowdebug/images/jdk/bin/java -XX:+PrintMethodData -XX:+Verbose -XX:TieredStopAtLevel=1 -Xcomp EmptyMain No MDOs are allocated in -XX:TieredStopAtLevel=1 + -Xcomp mode. The reason is TieredThresholdPolicy::should_create_mdo() always returns false because methods being compiled aren’t hot enough: bool TieredThresholdPolicy::call_predicate_helper(const methodHandle& method, CompLevel cur_level, int i, int b, double scale) { switch(cur_level) { ... case CompLevel_none: ... // Fall through case CompLevel_limited_profile: return (i >= Tier3InvocationThreshold * scale) \|\| (i >= Tier3MinInvocationThreshold * scale && i + b >= Tier3CompileThreshold * scale); (edited) With -XX:TieredStopAtLevel=3/4 -Xcomp some MDO allocations happening.
02-07-2020
Now that the test includes echoing of commands, the failed output is a bit more clear: Output: hsdb> hsdb> + verbose true hsdb> + printmdo -a hsdb> + printall <printall output follows> So as pointed out above, there is no "printmod -a" output.
01-07-2020
It looks like "printmdo -a", which normally produces a lot of output, is producing no output. The test execute the following clhsdb commands in sequence: "printmdo -a", "printall", "jstack -v". The CounterData symbol is suppose to be part of the "printmod -a" output. However, if you look in the log it looks like "printmdo -a" printed nothing, and the first lines of output you see are for the "printall" command: Here's the start of the output in the failing case: =================== Output: hsdb> hsdb> hsdb> private static java.util.function.Function get$Lambda(java.util.function.BiFunction) @0x00007f10a5c01730 Holder Class final [synthetic] class java.lang.WeakPairMap$$Lambda$3 @0x0000000800bc4c40 Compiled Code Disassembly for compiled method [private static java.util.function.Function get$Lambda(java.util.function.BiFunction) @0x00007f10a5c01730 ] @0x00007f10b511f090 Bytecode bci bytecode 0 new #2 [Class java.lang.WeakPairMap$$Lambda$3] 3 dup ... ====================== The above output is for printall, not printmdo. When working the start of the output looks like: ====================== Output: hsdb> hsdb> MethodData 0x00007fee601f6e38 for method jdk/internal/module/ModuleBootstrap$2.hasNext()Z@0x00000008002b9b20 0 bci: 4 VirtualCallData count(0) entries(1) InstanceKlass for java/util/HashMap$KeyIterator(120) 56 bci: 9 BranchData taken(81) displacement(120) not taken(39) 88 bci: 16 VirtualCallData count(0) entries(1) InstanceKlass for java/util/HashMap$KeyIterator(39) 144 bci: 21 BranchData taken(18) displacement(56) not taken(21) 176 bci: 25 JumpData taken(102) displacement(24) ... ====================== Notice: hsdb> hsdb> hsdb> vs hsdb> hsdb> MethodData 0x00007fee601f6e38 for method jdk/internal/module/ModuleBootstrap$2.hasNext()Z@0x00000008002b9b20 The second hsdb> prompt is for the printmdo command, and since it doesn't print anything in the failing case, the next output is the next hsdb> prompt.
11-04-2020
Issue is not only with TieredStopAtLevel=1, it is with combination -Xcomp. Running both (-XX:TieredStopAtLevel=1 and -Xcomp) individually didn't lead to crash. Crash observed with -vmoptions:"-Xcomp -XX:TieredStopAtLevel=1"
17-01-2020
Thank you [~thartmann] for the details.
17-12-2019
The real problem is: java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: 'CounterData' missing from stdout/stderr at ClhsdbCDSCore.main(ClhsdbCDSCore.java:207) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:832) Caused by: java.lang.RuntimeException: 'CounterData' missing from stdout/stderr at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:306) at ClhsdbLauncher.runCmd(ClhsdbLauncher.java:149) at ClhsdbLauncher.runOnCore(ClhsdbLauncher.java:219) at ClhsdbCDSCore.main(ClhsdbCDSCore.java:203)
17-12-2019
That test is supposed to crash, right? class CrashApp { public static void main(String[] args) { Unsafe.getUnsafe().putInt(0L, 0); } }
17-12-2019

Duplicate :	JDK-8248673 - serviceability/sa/ClhsdbCDSCore.java fails with "Exception: java.lang.RuntimeException: 'CounterData' missing from stdout/stderr"
Relates :	JDK-8271323 - [TESTBUG] serviceability/sa/ClhsdbCDSCore.java fails with -XX:TieredStopAtLevel=1