JDK-8293045 : notproduct flags should be invisible in product builds
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 20
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2022-08-29
  • Updated: 2024-04-02
  • Resolved: 2024-04-02
Related Reports
Relates :  
JDK-8292590 - Product JVM crashes with FLAG_SET_XXX on non-product Flag
Relates :  
JDK-8236736 - Change notproduct JVM flags to develop flags
Description
https://github.com/openjdk/jdk/blob/adb3d4f14af1974e7fc9461eb59f98131f0d33f7/src/hotspot/share/runtime/globals.hpp#L37-L41

// develop flags are settable / visible only during development and are constant in the PRODUCT version
// product flags are always settable / visible
// notproduct flags are settable / visible only during development and are not declared in the PRODUCT version
// develop_pd/product_pd flags are the same as develop/product, except that their default values
// are specified in platform-dependent header files.

However, we declare the notproduct flags in a product build anyway:

https://github.com/openjdk/jdk/blob/adb3d4f14af1974e7fc9461eb59f98131f0d33f7/src/hotspot/share/runtime/globals_shared.hpp#L77

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

After JDK-8292590, we will have a non-consistent behavior such that:

[1] Reading the flag works:

  if (UseDebuggerErgo) {


[2] But setting the flag will cause a C++ compile error

    FLAG_SET_ERGO_IF_DEFAULT(UseDebuggerErgo1, true);
Comments
Given that there are at least 10 notproduct flag that violate the property that notproduct shouldn't be materialized in non-PRODUCT builds, in multiple places, I think I'm not the only one to not understand the point of them. Plus the additional mental load of understanding the difference, and given that there's no performance benefit of having this difference, I'm closing this as WNF and reopening JDK-8236736. This second issue helps by simplifying the macros.
02-04-2024
I still stand by what I wrote in https://bugs.openjdk.org/browse/JDK-8236736?focusedId=14310044&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14310044. But if people don't understand the difference it serves no purpose.
01-04-2024
I can't get the suggested fix in the description to compile. The macros are defeating. We should close this as WNF and change all notproduct to develop as in JDK-8236736. It's a really nice cleanup as it reduces the macro parameters in all the cases, many that aren't used by the component defining the macro.
28-03-2024
I still absolutely fail to see the point of this. It's so we can have develop options but surround them and the code with the awesome #ifdef PRODUCT ? Because of this "bug" there are a lot of notproduct flags that are treated like develop flags and fail to compile when the "bug" is fixed. We used to care about the size of jvm.dll so maybe we wanted to force some flags to have code compiled with #ifndef PRODUCT.
28-03-2024
[~dholmes] You are correct. I fixed the bug description to refer to JDK-8292590
13-09-2022
> After JDK-8236736, we will have a non-consistent behavior [~iklam] did you mean "After JDK-8292590 ..."?
30-08-2022
We had it right in JDK 7: #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) I wonder where we broke it? Luckily we don't really care about notproduct builds other than develop builds these days. EDIT: Oh I see we already had this discussion in JDK-8236736.
29-08-2022