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.
Posted Date : 2007-10-18 17:31:10.0

N/A

Yes.
Posted Date : 2008-06-25 20:56:57.0

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.)
Posted Date : 2008-07-01 20:38:58.0

http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/d28aa69f0959
Posted Date : 2008-08-28 05:36:27.0