https://openjdk.org/jeps/483 mentions:

      To enjoy the benefits of the AOT cache generated during a training run,
      the training run and all subsequent runs must be essentially similar. [...]
      All runs must not use JVMTI agents that can arbitrarily rewrite classfiles
      using ClassFileLoadHook.

However, when *any* java agent is specified in the training run, the JVM fails at start-up. E.g.,

$ java -XX:AOTMode=record -javaagent:agent.jar -cp app.jar App
Error occurred during CDS dumping
Must enable AllowArchivingWithJavaAgent in order to run Java agent during CDS dumping

================
Proposal

The main concern for JVMTI agents is that they can modify the contents of loaded Java classes. If we store such modified classes into the AOT cache, their contents will no longer match the original class files (from application JAR files, etc). As a result, when using the AOT cache in production runs, the application may have unexpected behavior.

To address, we ensure that JVMTI agents cannot affect the contents of AOT cache:

[1] In training run (java -XX:AOTMode=record), JVMTI agents are allowed, but the AOTConfiguration file should filter out classes that are transformed by the agents. This can be checking InstanceKlass::has_been_redefined and ClassFileStream::from_class_file_load_hook().

[2] In the assembly phase (java -XX:AOTMode=record), agents can be specified in the command-line. However, since the assembly phase doesn't execute any application logic, we will also not load any of the specified agents. Therefore, the agents cannot affect the contents of the AOT cache created in the assembly phase.