RFR: 8356212: runtime/cds/appcds/LotsOfSyntheticClasses.java timed out with -XX:+AOTClassLinking

[Aleksey Shipilev]

On Thu, 8 May 2025 05:06:01 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> The LotsOfSyntheticClasses.java test times out intermittently when the `open/test/hotspot/jtreg:hotspot_aot_classlinking` test group is run with the` -XX:+AOTClassLinking` option on macosx-aarch64 platform.
> Increasing the timeout value from 500 to 800 seems to have addressed the issue.
> With the change, there's no timeout when the test group is run 40 times on macosx-aarch64 with the same option.

Quick profiling shows we spend _a lot_ of time in class inits and SystemDictionary verification. Some of this can be alleviated by skipping the verification.

Also, a different route: the test is a regression test for JDK-8342283. That bug is about backing storage in `Map<Class, ...>`, `List<Class, ...>` exceeding CDS archival limit (256KB). So nominally, we want 256KB / 4 bytes = 64K classes in this test.

So I propose in addition to bumping the timeout, we also optimize the test like this:


diff --git a/test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java b/test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java
index 96d2dc0d6ee..6267c6bdf33 100644
--- a/test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java
+++ b/test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java
@@ -42,9 +42,12 @@
 
 public class LotsOfSyntheticClasses {
 
-    // Generate 100 top-level classes, each containing 1000 nested classes.
-    // 100K total classes are more than enough to push the CDS limits.
-    private static final int NUM_CLASSES = 100;
+    // Generate 70 top-level classes, each containing 1000 nested classes.
+    // 70K total classes is enough to push the CDS limits. Any archived
+    // collection that holds Classes should not have backing storage larger
+    // than CDS archival limit (256KB). This means we want at least 64K classes
+    // to probe that limit.
+    private static final int NUM_CLASSES = 70;
     private static final int NUM_NESTED_CLASSES = 1000;
 
     private static final Path USER_DIR = Paths.get(CDSTestUtils.getOutputDir());
@@ -117,7 +120,11 @@ public static void main(String[] args) throws Exception {
             OutputAnalyzer output = TestCommon.createArchive(
                 APP_JAR.toString(),
                 listAppClasses(),
-                MAIN_CLASS_NAME
+                MAIN_CLASS_NAME,
+                // Verification for lots of classes slows down the test.
+                "-XX:+IgnoreUnrecognizedVMOptions",
+                "-XX:-VerifyDependencies",
+                "-XX:-VerifyBeforeExit"
             );
             TestCommon.checkDump(output);
         }
@@ -125,9 +132,10 @@ public static void main(String[] args) throws Exception {
         // Step 3. Try to run, touching every class.
         {
             TestCommon.run(
-                // Verifying dependencies for lots of classes slows down the test.
-                "-XX:+IgnoreUnrecognizedVMOptions", "-XX:-VerifyDependencies",
-                "-Xlog:cds",
+                // Verification for lots of classes slows down the test.
+                "-XX:+IgnoreUnrecognizedVMOptions",
+                "-XX:-VerifyDependencies",
+                "-XX:-VerifyBeforeExit",
                 "-cp", APP_JAR.toString(),
                 MAIN_CLASS_NAME).
                     assertNormalExit("Success");


This cuts the test time about 4x on my macos-aarch64-debug.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25111#issuecomment-2863504243