Seen this in AOT experiments. When application fails abruptly during training, we still invoke the AOT cache creation. This is likely unexpected, as the failure like this in production would likely be a show-stopper as well. It is also not very symmetric with 3-step workflow: if AOTMode=record had the application exiting abnormally, the scripts would likely *not* proceed to AOTMode=create.

For AOT usability perspective, abrupt application termination likely makes training incomplete, so we spend time creating the AOT archive that is: a) might not be as efficient; b) would likely be thrown away by user as incomplete.

We should consider checking if application shutdown correctly before going for AOT cache creation. There is a caveat: if there is an application that sits tight in some sort of event loop, and user terminates it with Ctrl+C (or SIGTERM), we should be generating the AOT archive in that conditions.

See:

% cat Crashy.java
public class Crashy {
public static void main(String... args) {
throw new RuntimeException("Nobody expects the Spanish Inquisition!");
}
}

% build/macosx-aarch64-server-fastdebug/images/jdk/bin/java -XX:AOTCacheOutput=crashy.aot Crashy.java
Exception in thread "main" java.lang.RuntimeException: Nobody expects the Spanish Inquisition!
at Crashy.main(Crashy.java:3)
Temporary AOTConfiguration recorded: crashy.aot.config
Launching child process build/macosx-aarch64-server-fastdebug/images/jdk/bin/java to assemble AOT cache crashy.aot using configuration crashy.aot.config
Picked up JAVA_TOOL_OPTIONS: --add-modules=ALL-DEFAULT -XX:AOTCacheOutput=crashy.aot -XX:AOTConfiguration=crashy.aot.config -XX:AOTMode=create
Reading AOTConfiguration crashy.aot.config and writing AOTCache crashy.aot
AOTCache creation is complete: crashy.aot 25444352 bytes
Removed temporary AOT configuration file crashy.aot.config