JDK-8227439 : Turn off AOT by default
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10,11,12,13,14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-07-09
  • Updated: 2021-04-01
  • Resolved: 2019-08-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 14
11.0.6-oracleFixed 13.0.4Resolved 14 b10Fixed
Related Reports
CSR :  
Sub Tasks
JDK-8228418 :  
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
Fix request (13u) I'd like to backport this to 13u tier1 tests passed Applies cleanly

I see that the original change required a CSR, but I don't see a CSR for JDK 11 (due to the Oracle backport). Was this an oversight or intentional?

Fix request (11u) I'd like to downport this for parity with Oracle jdk-11.0.6. I had to do some minor adaptions to apply it to jdk11u-dev: http://cr.openjdk.java.net/~goetz/wr19/8227439-Turn_off_AOT-jdk11/01/ http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-November/002101.html I ran it through our testing. I suspected there would be some additional tests that need adaptions, but it's all green.

HI [~sgehwolf], Thank you for the comments. Yes unfortunately I missed to initiate a CSR for Oracle 11 backport before commits. So now initiated a CSR now with details (JDK-8232090). Awaiting comments/approval fro the same.

[~rraghavan] File backport for JDK 13 too since you plan to fix it in JDK 11.


URL: https://hg.openjdk.java.net/jdk/jdk/rev/41f2f2829a09 User: rraghavan Date: 2019-08-08 08:44:51 +0000

[~rraghavan] Yes, PrintAOT should be also experimental.

Hi [~kvn], should we make 'PrintAOT' flag also experimental?

Yes, it needs CSR since it is product flag. It is not urgent - fix it in JDK 14.

## Made UseAOT, AOTLibrary experimental and UseAOT false by default ---- [src/hotspot/share/runtime/globals.hpp] /* AOT parameters */ \ - product(bool, UseAOT, AOT_ONLY(true) NOT_AOT(false), \ + experimental(bool, UseAOT, false, \ "Use AOT compiled files") \ \ - product(ccstrlist, AOTLibrary, NULL, \ + experimental(ccstrlist, AOTLibrary, NULL, \ "AOT library") \ ---- Also added required -XX:+UnlockExperimentalVMOptions, related changes in tests <webrev.00> - http://cr.openjdk.java.net/~rraghavan/8227439/webrev.00/

Most changes would be in AOT tests and test tasks.

I think to make change small for backport we implement only 1) and 3).