JDK-6618726 : Introduce -XX:+UnlockExperimentalVMOptions flag
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2007-10-18
  • Updated: 2017-05-16
  • Resolved: 2011-03-07
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 6 JDK 7 Other
6u14Fixed 7Fixed hs14Fixed
Related Reports
Relates :  
In HotSpot we sometimes introduce features under -XX flags that we would like to consider experimental for some time before officially supporting them (once we are satisfied of their reliability). However, we do not have a clear way to tell our users which options to consider as experimental. 

This CR proposes the introduction of a new flag -XX:+UnlockExperimentalVMOptions. Only when this flag is set, options deemed experimental will actually be allowed to be set. Such options will be tagged in globals.hpp with experimental(...), in the same way that today they are tagged with product(...) and/or debug(...). It basically follows the way diagnostic options are tagged, with diagnostic(...), and unlocked, with -XX:+UnlockDiagnosticVMOptions.

There are several advantages to this approach.

- It will be a warning to the customers that the options they are using are considered experimental.
- Upon a customer complaint, it will allows us to quickly grep through their cmd line options to find out whether they were using an option they were not supposed to (without having to work out whether option XXX was considered experimental in release YYY).
- It will make it easier to introduce half-baked work in the VM, given the more aggressive release schedule through HotSpot Express.

First VM options that we are planning to add under the experimental blanket is -XX:+UseG1GC.

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/d28aa69f0959

EVALUATION The fix is in the G1 workspace whence it will flow into open jdk when G1 integrates. See also related CR's for a small clean-up possible (in a separate CR) in the support of experiment() and diagnostic(), to the elimination of what appears to be a somewhat unnecessary is_unlocker() method. (But see related email in comments section.)

SUGGESTED FIX repo: /net/jano2/export2/hotspot/hg/hotspot-g1-gc changeset: 217:d28aa69f0959 user: ysr date: Mon Jun 30 17:04:59 2008 -0700 description: 6618726: Introduce -XX:+UnlockExperimentalVMOptions flag Summary: experimental() flags will protect features of an experimental nature that are not supported in the regular product build. Made UseG1GC an experimental flag. Reviewed-by: jmasa, kamg, coleenp files: src/share/vm/gc_implementation/g1/g1_globals.cpp src/share/vm/gc_implementation/g1/g1_globals.hpp src/share/ vm/runtime/globals.cpp src/share/vm/runtime/globals.hpp src/share/vm/runtime/globals_extension.hpp src/share /vm/services/management.cpp ----- repository=/net/jano2/export2/hotspot/hg/hotspot-g1-gc,changeset=d28aa69f0959,changerequest=6618726