Summary

Add a JVM option: -XX:+AOTClassLinking to control the new behavior introduced in JEP 483

Problem

JEP 483 allows classes in an AOT cache (historically known as a "CDS archive") to

• be bulk-loaded during JVM start-up
• have some of their symbolic references to other classes to be resolved ahead of time and replaced with direct pointer references

The new behavior of JEP 483 changes the order of when classes are loaded. This may affect some applications that rely on a specific order of class loading. E.g., some applications may assume that when class A is executed, class B is not yet loaded, so class A may attempt to dynamically define a different version of B. If both classes A and B are loaded immediately at JVM start-up, the dynamical definition of B would fail with a LinkageError.

Solution

Although the Java specification does not guarantee the order of class loading, to ensure backwards compatibility with such applications, we use the AOTClassLinking flag to control whether the JEP 483 behavior is enabled.

Specification

An option AOTClassLinking of the bool type is added to the list of HotSpot JVM options.

• When an AOT cache is created with the new -XX:AOTMode=create flag, we assume that the application is aware of AOT class linking and does not depend of the class loading order. In this case, AOTClassLinking has a default value of true. The user can disable it by explicitly passing -XX:-AOTClassLinking in the JVM command line.

• When an AOT cache is created with existing "CDS" flags (-Xshare:dump, -XX:ArchiveClassesAtExit, -XX:+AutoCreateSharedArchive), as well as existing jcmd VM.cds commands, we assume that the the application may not be aware of AOT class linking. Therefore, AOTClassLinking has a default value of false. The user can enable it by explicitly passing -XX:+AOTClassLinking in the JVM command line to indicate that the application makes no assumptions about class loader order.