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