On Wed, 16 Sep 2026 19:10:42 GMT, Robert Toyonaga <[email protected]> wrote:
> ### Summary > > When specifying `-XX:UnlockDiagnosticVMOptions` without the necessary +/-, > the following error is produced: > > $ java -XX:UnlockDiagnosticVMOptions -m jdk.httpserver > Error: VM option 'UnlockDiagnosticVMOptions' is diagnostic and must be > enabled via -XX:+UnlockDiagnosticVMOptions. > > > Similarly with `-XX:UnlockExperimentalVMOptions`: > > $ java -XX:UnlockExperimentalVMOptions -m jdk.httpserver > Error: VM option 'UnlockExperimentalVMOptions' is experimental and must be > enabled via -XX:+UnlockExperimentalVMOptions. > > > This recursive complaint about using the unlocker to unlock the unlocker is > misleading and probably confusing for users. > > ### Root cause > The problem is that `UnlockDiagnosticVMOptions` is **itself** a _diagnostic_ > option. And `UnlockExperimentalVMOptions` is **itself** an _experimental_ > option. > > `Arguments::process_argument` calls `parse_argument` which notices > `UnlockDiagnosticVMOptions`/`UnlockExperimentalVMOptions` is missing +/- so > leaves the option **unset**. Since the unlocker option is unset, and the > unlocker option is itself diagnostic/experiemental, the "must be enabled" > error is thrown because it hasn't yet been unlocked. > > UnlockDiagnosticVMOptions defaults to true in debug, so the problem only > manifests in release builds. > UnlockExperimentalVMOptions always defaults to false, so the problem > manifests in all builds. > > > ### Solution > The solution is to treat `UnlockDiagnosticVMOptions` and > `UnlockExperimentalVMOptions` as always unlocked. The existing Hotspot code > already essentially does this, but this PR formalizes it in > `JVMFlag::is_unlocked()`. As an added benefit, this allows for some > simplification in other places too where we check the status of flags. > > > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). Overall this seems a reasonable change to make. The locked status of the unlocking flags was always a bit odd. There is one bug - which suggests we are missing some test coverage. Thanks src/hotspot/share/prims/whitebox.cpp line 1364: > 1362: WB_ENTRY(jboolean, WB_IsLockedVMFlag(JNIEnv* env, jobject o, jstring > name)) > 1363: const JVMFlag* flag = getVMFlag(thread, env, name); > 1364: return (flag != nullptr) && flag->is_unlocked(); Suggestion: return (flag != nullptr) && !flag->is_unlocked(); This code is wrong. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/32910#pullrequestreview-5242165644 PR Review Comment: https://git.openjdk.org/jdk/pull/32910#discussion_r4042041285
