JDK-8024137 : Flags should be set using the proper macro
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 8,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-09-02
  • Updated: 2016-08-11
  • Resolved: 2016-07-12
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 9
9 b131Fixed
Related Reports
Blocks :  
Duplicate :  
Description
The tracing framework has events that reports all flags in the VM, similar to -XX:+PrintFlagsFinal. These events contains the origin of the value of each flag, that is if it is set on the command line, if it has been changed by ergonomics or if it has the default value. In some places in the code we change the value of a flag using plain assignment. This means that we change the value but doesn't update the origin of the value. The result is that the flags will be reported as having default values when they don't, or maybe more confusing for the user, as being set on the command line but having a different value then what was set on the command line.

We should make sure all flag changes use the proper macros so that the origin is updated as well. Also we should make sure no ergonomic updates are made using the FLAG_SET_CMDLINE macro. Only the user should set the command line.

We also have the case where a flag is set on the command line and later changed by the ergonomics (FLAG_SET_ERGO). After this, the question FLAG_IS_CMDLINE will reply false. This makes the policy code more difficult to write and maintain since we will have to use a separate variable to remember that the flag was set on the command line in cases where the value is not really changed by the ergonomics, only slightly adjusted. For instance if a memory size is aligned to a page size or similar.
In some cases we have chosen to update a flag variable without using the proper macro for doing so which will have other consequences.

Another similar problem is the command line flags that we put in the gc log file when using -Xloggc. Here we print all flags that are not labeled as default as if they were specified on the command line. This is not true since lots of flags are changed by ergonomics. To print the proper flags we need to save which flags was specified on the command line. We should also add another line to the log file and print the flags that was not specified on the command line but changed by ergonomics, so that we don't remove information that is present in the log file today.

To clean up the initialization code and fix the bug in the log file we should change the flag implementation to store its state in a persistent manner so that we can ask if a flag was set on the command line and if it was set by the ergonomics and get truthful answers in all cases.
Comments
Giving this to the GC groups since many of the ergonomics flags are GC flags.
16-05-2016

It seems this issue has been reported by users outside of Oracle as well. We should not defer it without more investigation. Setting it back to 9.
10-03-2016

This bug is targeted for 9.1, but the umbrella CR is targeted for 9. Jesper, can you resolve that inconsistency somehow?
10-03-2016

I have started on an implementation but it's not anywhere near finished. Since I'm not actively working on this I'll unassign myself.
01-03-2016

Please note that in the current code it is in some cases deliberate not to use the macro. For instance with MaxNewRatio the ergonomics relies on checking if it is set on the command line in TwoGenerationalColletorPolicy::initialize_flags(), but already in GenCollectorPolicy::initialize_flags() the flag could be aligned by the ergonomics. A similar pattern is found for MetaspaceSize and MaxMetaspaceSize. This should be fixed.
05-03-2014