JEP 295 AOT is still experimental, and while it can be useful for startup/warmup when used with custom generated archives tailored for the application, experimental data suggests that generating shared libraries at a module level has overall negative impact to startup, dubious efficacy for warmup and severe static footprint implications.

Thus I think there are a few dubious design decisions made by JEP 295 that should be reconsidered:

1) -XX:+UseAOT is on by default, and not guarded by -XX:+UnlockExperimentalVMOptions
2) By default, the VM searches a few ill-documented paths in the JRE directory structure and attempts to load these as shared libraries

These combined means the feature is having an impact to cold startup for users not interested in or unaware of the AOT, which in my opinion is not acceptable for an experimental feature. The design is also "magically" implicit in nature, which means it probably breaks the principle of least astonishment.

I suggest we do the following, in descending order of priority:

1) Turn off UseAOT by default
2) Remove the loading in of a hardcoded list of shared libraries (alternatively make that list configurable)
3) Make use of UseAOT and AOTLibrary guarded by UnlockExperimentalVMOptions