New boolean diagnostic flag -XX:+ExitOnAOTCacheMismatch.
The flag defaults to false, of course.
(The eager-exit behavior it controls is problematic because AOT cache mismatch is difficult to predict, perhaps impossible sometimes. For example, GC ergonomics can change heap size at startup, but some compressed oop settings dependon heap size, and there might be code in the AOT cache that only works with a particular kind of compressed oop.)
An explicit command line setting overrides the default, requesting VM exit if there is any significant (error-level) AOT cache mismatch.
The status of this flag is akin to the non-product flag `-XX+ExitOnFullCodeCache`.
(By making it diagnostic instead of non-product, we would be raising the profile file of this flag slightly, to achieve behavioral compatibility with the old VM-exiting behaviors of `-Xshare:on` and `AOTMode=on`. Arguably, this existing behavior is almost useless, since VM exit is a poor diagnostic, compared to logging warnings and errors.)
New -Xlog events as needed to diagnose various kinds of AOT cache mismatch.
-Xlog events that are error level are *exactly* the events which will cause the VM to exit, *if* ExitOnAOTCacheMismatch is true.
If such a VM exit happens, we claim this follows the JVM specification, and appeal to existing JVMS language about VirtualMachineError, which covers this case, as a non-recoverable “resource”.
The pre-existing commands `-XX:AOTMode=on` and `-Xshare:on` are CHANGED so that eager-exit on AOT mismatch is NO LONGER enabled by `on`, but must be separately enabled by this new flag.
(This change is arguably compatible, even if the VM never exits again due to AOT cache mismatch. Every VM run will forge ahead, going a little slower, instead of exiting. It's as if the VM always finds **something** to like about the AOT cache, even as it complains about **most** of the cache being bad. And who will complain about crashing less? Very few.)
The new (residual) meaning of `AOTMode=on` is an explicit user selection of a production run, as opposed to a training run. That is, `AOTMode=record` or `AOTMode=on` are explicit options for specifying training or production, respectively, and a missing AOT mode (or `AOTMode=auto`) means "auto-select from other options".
In the future, if "auto-training" workflows are implemented, the AOT mode `auto` may acquire additional meanings, such as "train sometimes". In such futures, `on` and `record` are always available to make the choice less automatic and more explicit.
The flag defaults to false, of course.
(The eager-exit behavior it controls is problematic because AOT cache mismatch is difficult to predict, perhaps impossible sometimes. For example, GC ergonomics can change heap size at startup, but some compressed oop settings dependon heap size, and there might be code in the AOT cache that only works with a particular kind of compressed oop.)
An explicit command line setting overrides the default, requesting VM exit if there is any significant (error-level) AOT cache mismatch.
The status of this flag is akin to the non-product flag `-XX+ExitOnFullCodeCache`.
(By making it diagnostic instead of non-product, we would be raising the profile file of this flag slightly, to achieve behavioral compatibility with the old VM-exiting behaviors of `-Xshare:on` and `AOTMode=on`. Arguably, this existing behavior is almost useless, since VM exit is a poor diagnostic, compared to logging warnings and errors.)
New -Xlog events as needed to diagnose various kinds of AOT cache mismatch.
-Xlog events that are error level are *exactly* the events which will cause the VM to exit, *if* ExitOnAOTCacheMismatch is true.
If such a VM exit happens, we claim this follows the JVM specification, and appeal to existing JVMS language about VirtualMachineError, which covers this case, as a non-recoverable “resource”.
The pre-existing commands `-XX:AOTMode=on` and `-Xshare:on` are CHANGED so that eager-exit on AOT mismatch is NO LONGER enabled by `on`, but must be separately enabled by this new flag.
(This change is arguably compatible, even if the VM never exits again due to AOT cache mismatch. Every VM run will forge ahead, going a little slower, instead of exiting. It's as if the VM always finds **something** to like about the AOT cache, even as it complains about **most** of the cache being bad. And who will complain about crashing less? Very few.)
The new (residual) meaning of `AOTMode=on` is an explicit user selection of a production run, as opposed to a training run. That is, `AOTMode=record` or `AOTMode=on` are explicit options for specifying training or production, respectively, and a missing AOT mode (or `AOTMode=auto`) means "auto-select from other options".
In the future, if "auto-training" workflows are implemented, the AOT mode `auto` may acquire additional meanings, such as "train sometimes". In such futures, `on` and `record` are always available to make the choice less automatic and more explicit.
- relates to
-
JDK-8341676 [premain] fine-grained diagnosis of AOT cache assets
-
- Open
-