JDK-8236736 : Change notproduct JVM flags to develop flags
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 15
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-01-07
  • Updated: 2024-04-09
  • Resolved: 2024-04-03
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 23
23 b17Fixed
Related Reports
Relates :  
JDK-8293045 - notproduct flags should be invisible in product builds
Relates :  
JDK-8236754 - nonproduct and develop flags should not be printed by product build
Relates :  
JDK-6258968 - Global flags cleanup for C1 and C2
Relates :  
JDK-8236625 - Remove writeable macro from JVM flags declaration
Description
According to 
http://hg.openjdk.java.net/jdk/jdk/file/2fbc66ef1a1d/src/hotspot/share/runtime/globals.hpp#l38

// develop flags are settable / visible only during development and are constant in the PRODUCT version
// notproduct flags are settable / visible only during development and are not declared in the PRODUCT version

which seems to suggest that using a nonproduct flag in a product build would result in a compiler error of non-declared variable.

However, in the bottom of globals.hpp, nonproduct flags are declared in product build anyway. There doesn't seem to be any practical differences between nonproduct and develop flags.

#ifdef PRODUCT
#define DECLARE_DEVELOPER_FLAG(type, name, value, doc)    const type name = value;
#define DECLARE_PD_DEVELOPER_FLAG(type, name, doc)        const type name = pd_##name;
#define DECLARE_NOTPRODUCT_FLAG(type, name, value, doc)   const type name = value;

For simplicity, we should change all  nonproduct flags to develop flags.
Comments
Changeset: bea493bc Author: Coleen Phillimore <coleenp@openjdk.org> Date: 2024-04-03 12:21:11 +0000 URL: https://git.openjdk.org/jdk/commit/bea493bcb86370dc3fb00d86c545f01fc614e000
03-04-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/18541 Date: 2024-03-28 22:53:22 +0000
02-04-2024
A notproduct flag is to control something in a non-product build, relating to code that only exists in a non-product build. It has zero meaning in a product build. A develop flag provides a means to do things one way in a product build (using the default value of the flag), yet allow things to be done differently in a non-product build for testing/diagnostics/debugging. Both concepts are useful IMO to convey intent and usage in relation to the flag.
08-01-2020
How? So for the last 5 years we haven't had this feature that we should have missed? How is this notproduct useful? Give an example.
08-01-2020
Notwithstanding that 8024545 allowed the existence of a nonproduct flag to be visible in a product binary, the concepts of a notproduct flag versus a develop flag are distinct and useful IMO. Could we live with only develop? Sure. But I think conceptually both are useful to indicate the intent and usage of the flag.
08-01-2020
You can't read something that isn't there. To clarify, the flag may show up in a list of flags, but that serves no purpose AFAICS. The flag has no value and affects nothing because there can be no code in the product binary that relates to that flag. It is like showing a sparc-only flag in an x86 binary.
08-01-2020
[~coleenp] I think the distinction is useful and always has been useful.
08-01-2020
JDK-8024545 says: "Sometimes it is useful to ... read these values for compiler settings for a Java-based compiler.". So maybe JVMCI-based compilers, such as graal, do read the value of the non-product flag and do something with them? Need to double-check.
08-01-2020
Thanks. For some reason my source sleuthing hit a dead end with this change. So I guess the question is: is this distinction meaningful at all to make it worth the extra complexity overhead? Which took several comments to explain to me. What is the benefit? Why would we want this?
08-01-2020
Yes that is exactly my point - JDK-8024545 should not have made any changes to nonproduct. Of course it is possible that because of 8024545 notproduct flags have been used incorrectly and we won't have noticed.
08-01-2020
nonproduct flags are supposed to be used only within #ifndef PRODUCT blocks. So the C compiler will not see these flags at all.
08-01-2020
It used to be as quoted in the synopsis: - develop was a constant value in the code and could not be changed - notproduct flag did not exist at all and so could not be ever referenced from product code #define MATERIALIZE_NOTPRODUCT_FLAG(type, name, value, doc) 8024545 changed that. The change made some sense for develop flags, but not IMO for notproduct.
07-01-2020
And then this change gives one a good error message if you use a develop flag in product mode: JDK-8027314 I don't think we should expose users to develop flags, especially when we want to remove them when they're no longer useful. I'm still confused about the distinction between nonproduct flags and develop flags. The macros are the same. I can't see the JDK-8024545 changeset, maybe they used to be different. If you have: const bool flag = true; if (flag) { some code } won't the compiler not generate this code with the now-same definitions of develop and notproduct?
07-01-2020
JDK-6258968 added notproduct so that the code to test the flag wasn't executed in product mode.
07-01-2020
JDK-8024545: make develop and notproduct flag values available in product builds is what changed the behaviour. Looking now I think JDK-8024545 was wrong to include notproduct flags in its change because such flags could not exist in a product build and no code in a product build could ever reference them or act on their value. So there was no reason to try to expose them.
07-01-2020
Do we actually have usage of such flags that is not guarded by #ifndef PRODUCT ? I'd be looking at making the code work as described rather than removing the notion of "notproduct" flags. Need to dig into the history here as we used to have: #define MATERIALIZE_NOTPRODUCT_FLAG(type, name, value, doc) for a product build.
07-01-2020