JDK-8081519 : Split globals.hpp to factor out the Flag class
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-05-29
  • Updated: 2019-06-20
  • Resolved: 2018-04-23
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 11
11 b11Fixed
Related Reports
Blocks :  
JDK-8059557 - JEP 245: Validate JVM Command-Line Flag Arguments
Cloners :  
JDK-8202150 - [REDO] Split globals.hpp to factor out the Flag class
Relates :  
JDK-8078556 - Runtime: implement ranges (optionally constraints) for those flags that have them missing
Relates :  
JDK-8200746 - Remove FlagGuard class
Relates :  
JDK-8122937 - JEP 245: Validate JVM Command-Line Flag Arguments Implementation
Relates :  
JDK-8202151 - [BACKOUT] Split globals.hpp to factor out the Flag class
Description
Split globals.hpp to factor out the Flag values needed by JDK-8059557

The work for JEP: JDK-8059557 required that Flag::Error enum is available to other files. Perhaps we can factor out those values out of globals.hpp, which contains a whole lot of other APIs, that the other files do not need.
Comments
I'm aware of the breakage, working on backing it out: JDK-8202151
23-04-2018
This appears to have broken my build. In file included from /home/martin/ws/jdk/src/hotspot/share/runtime/globals.hpp:2800:0, from /home/martin/ws/jdk/src/hotspot/share/memory/allocation.hpp:28, from /home/martin/ws/jdk/src/hotspot/share/oops/array.hpp:28, from /home/martin/ws/jdk/src/hotspot/share/memory/universe.hpp:28, from /home/martin/ws/jdk/src/hotspot/share/code/oopRecorder.hpp:28, from /home/martin/ws/jdk/src/hotspot/share/asm/codeBuffer.hpp:28, from /home/martin/ws/jdk/src/hotspot/share/asm/assembler.hpp:28, from /home/martin/ws/jdk/src/hotspot/share/asm/macroAssembler.hpp:28, from /home/martin/ws/jdk/src/hotspot/share/interpreter/abstractInterpreter.cpp:26: /home/martin/ws/jdk/src/hotspot/share/runtime/globals_ext.hpp:48:13: error: 'JVMFlag' has not been declared inline bool JVMFlag::is_unlocker_ext() const { ^ On Ubuntu 16.04 bash ./configure --disable-warnings-as-errors --with-boot-jdk=/home/martin/jdk/jdk10 && make jdk-image Tools summary: * Boot JDK: java version "10.0.1" 2018-04-17 Java(TM) SE Runtime Environment 18.3 (build 10.0.1+10) Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.1+10, mixed mode) (at /home/martin/jdk/jdk10) * Toolchain: gcc (GNU Compiler Collection) * C Compiler: Version 5.4.0 (at /usr/bin/gcc) * C++ Compiler: Version 5.4.0 (at /usr/bin/g++)
23-04-2018
JVMFlag is nice and short, I like it, though we already have a bunch of files names with the prefix "commandLine", so we'd need to rename them all, but if we're going through all this trouble, then maybe it's worth it.
15-03-2018
JVMFlag?
13-03-2018
I agree about the Flag being a too generic name, but we already have a class named CommandLineFlags (notice the plural). Maybe I can merge Flag & CommandLineFlags into just CommandLineFlag or CommandLineFlags?
13-03-2018
I don't know how anyone else feels about this, but I think Flag is a horribly generic name for the class. I'd be happy to see it renamed to CommandLineFlag and the files named correspondingly.
13-03-2018
[~kbarrett] What if I move the Flag class out of globals.hpp/.cpp and into: #1 flags.hpp/.cpp or #2 commandLineFlags.hpp/cpp? I personally prefer #2, since it describes the purpose of the file better.
13-03-2018
Please don't dump more stuff into globalDefinitions.hpp.
01-06-2017
Maybe flag values belong in globalDefinitions.hpp ?
01-06-2015
Based on review comment from Kim: "Many files are being changed to #include globals.hpp just to get access to Flag values. Perhaps globals.hpp ought to be split up. This probably ought to be addressed as a separate CR though."
01-06-2015