Diagnostic options are orthogonal to debug builds. Having UnlockDiagnosticVMOptions set to true in debug builds is just confusing and can result in unexpected test failures as we could see in JDK-8153655.
[~stefank] and [~vlivanov] pointed out that developers frequently use these common flags during development with non-product builds and having to specify -XX:+UnlockDiagnosticVMOptions would be a daily hindrance:
diagnostic(bool, PrintAssembly, false, \
diagnostic(ccstr, PrintAssemblyOptions, NULL, \
diagnostic(bool, PrintNMethods, false, \
diagnostic(bool, PrintInlining, false, \
diagnostic(bool, VerifyBeforeGC, false, \
diagnostic(bool, VerifyAfterGC, false, \
diagnostic(bool, VerifyDuringGC, false, \
diagnostic(bool, UseNewCode, false, \
26-01-2018
I don't want this proposed change. -XX:+UnlockDiagnosticVMOptions exists so that customers don't accidentally turn on these flags, it's not there to make it harder for us developers to turn on diagnostic features.
26-01-2018
Exactly my point! Thanks, Coleen.
25-01-2018
I agree, this is annoying that you can develop and run your test, and be surprised to find that you are missing this flag that's different in debug mode for no good reason.
24-01-2018
I don't see why it should be confusing, we do a few things differently in debug/notproduct builds. The only issue may be tests that don't specify it and then run against product builds. That should not be an issue as the test writers should be testing with both product and non-product.
18-04-2016
No code; the flag itself:
656: diagnostic(bool, UnlockDiagnosticVMOptions, trueInDebug, \