RFR: 8255285: Move JVMFlag origins into a new enum JVMFlagOrigin

David Holmes david.holmes at oracle.com
Fri Oct 23 07:34:45 UTC 2020


Hi Ioi,

On 23/10/2020 4:52 pm, Ioi Lam wrote:
> Many JVM function take an `JVMFlag::Flags` parameter to indicate the origin of the flag -- i.e., "who is setting this flag". E.g., in arguments.hpp:
> 
> static bool parse_argument(const char* arg, JVMFlag::Flags origin);
> 
> However, `JVMFlag::Flags` contains many other bits that are unrelated to the origin. We should add a new enum `JVMFlagOrigin` that has only the valid values for the origin. This makes it possible to do more type-safety checks at C++ compilation time.
> 
> This patch also renamed the confusing bit `JVMFlag::ORIG_COMMAND_LINE` to `WAS_SET_IN_COMMAND_LINE` and added documentation, so that it won't be confused with `JVMFlagOrigin::COMMAND_LINE`.

I'm still confused :) Why are we reporting "command line" for a flag 
that was ergonomically set, or vice-versa? Surely a flag is either set 
via the command-line or via ergonomics but not both ?? I was under the 
assumption that ergonomics should not touch a flag explicitly set on the 
command-line as that defeats the purpose of setting it.

 > enum class JVMFlagOrigin

Why not define this as

enum class Origin

inside class JVMFlag, so that it is then referred to as JVMFlag::Origin?

 >  static const JVMFlagOrigin DEFAULT          = JVMFlagOrigin::DEFAULT;

Why is this needed?? To avoid re-typing JVMFlagOrigin?

Cheers,
David
-----

> -------------
> 
> Commit messages:
>   - fixed whitespaces
>   - jvmflagorigin
> 
> Changes: https://git.openjdk.java.net/jdk/pull/823/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=823&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8255285
>    Stats: 173 lines in 19 files changed: 49 ins; 14 del; 110 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/823.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/823/head:pull/823
> 
> PR: https://git.openjdk.java.net/jdk/pull/823
> 


More information about the hotspot-dev mailing list