8264285: Clean the modification of ccstr JVM flags #3254
Conversation
|
|
Webrevs
|
|
Hi Ioi, This looks good to me. Thanks for fixing it up. One minor nit below. Thanks, |
| if (err == JVMFlag::SUCCESS) { | ||
| assert(value == NULL, "old value is freed automatically and not returned"); | ||
| } |
dholmes-ora
Mar 30, 2021
Member
The whole block should be ifdef DEBUG.
The whole block should be ifdef DEBUG.
iklam
Mar 31, 2021
Author
Member
Since this whole block can be optimized out by the C compiler in product builds, I'd rather leave out the #ifdef to avoid clutter.
Since this whole block can be optimized out by the C compiler in product builds, I'd rather leave out the #ifdef to avoid clutter.
|
@iklam This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be: You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been no new commits pushed to the
|
|
I had a question but overall nice cleanup! |
| // Unlike the other APIs, the old vale is NOT returned, so the caller won't need to free it. | ||
| // The callers typically don't care what the old value is. | ||
| // If the caller really wants to know the old value, read it (and make a copy if necessary) | ||
| // before calling this API. |
coleenp
Mar 31, 2021
good comment!
good comment!
| // For example, DummyManageableStringFlag is needed because we don't | ||
| // have any MANAGEABLE flags of the ccstr type, but we really need to | ||
| // make sure the implementation is correct (in terms of memory allocation) | ||
| // just in case someone may add such a flag in the future. |
coleenp
Mar 31, 2021
Could you have just added a develop flag to the manageable flags instead?
Could you have just added a develop flag to the manageable flags instead?
iklam
Mar 31, 2021
Author
Member
I had to use a product flag due to the following code, which should have been removed as part of JDK-8243208, but I was afraid to do so because I didn't have a test case. I.e., all of our diagnostic/manageable/experimental flags were product flags.
With this PR, now I have a test case -- I changed DummyManageableStringFlag to a notproduct flag, and removed the following code. I am re-running tiers1-4 now.
void JVMFlag::check_all_flag_declarations() {
for (JVMFlag* current = &flagTable[0]; current->_name != NULL; current++) {
int flags = static_cast<int>(current->_flags);
// Backwards compatibility. This will be relaxed/removed in JDK-7123237.
int mask = JVMFlag::KIND_DIAGNOSTIC | JVMFlag::KIND_MANAGEABLE | JVMFlag::KIND_EXPERIMENTAL;
if ((flags & mask) != 0) {
assert((flags & mask) == JVMFlag::KIND_DIAGNOSTIC ||
(flags & mask) == JVMFlag::KIND_MANAGEABLE ||
(flags & mask) == JVMFlag::KIND_EXPERIMENTAL,
"%s can be declared with at most one of "
"DIAGNOSTIC, MANAGEABLE or EXPERIMENTAL", current->_name);
assert((flags & KIND_NOT_PRODUCT) == 0 &&
(flags & KIND_DEVELOP) == 0,
"%s has an optional DIAGNOSTIC, MANAGEABLE or EXPERIMENTAL "
"attribute; it must be declared as a product flag", current->_name);
}
}
}
I had to use a product flag due to the following code, which should have been removed as part of JDK-8243208, but I was afraid to do so because I didn't have a test case. I.e., all of our diagnostic/manageable/experimental flags were product flags.
With this PR, now I have a test case -- I changed DummyManageableStringFlag to a notproduct flag, and removed the following code. I am re-running tiers1-4 now.
void JVMFlag::check_all_flag_declarations() {
for (JVMFlag* current = &flagTable[0]; current->_name != NULL; current++) {
int flags = static_cast<int>(current->_flags);
// Backwards compatibility. This will be relaxed/removed in JDK-7123237.
int mask = JVMFlag::KIND_DIAGNOSTIC | JVMFlag::KIND_MANAGEABLE | JVMFlag::KIND_EXPERIMENTAL;
if ((flags & mask) != 0) {
assert((flags & mask) == JVMFlag::KIND_DIAGNOSTIC ||
(flags & mask) == JVMFlag::KIND_MANAGEABLE ||
(flags & mask) == JVMFlag::KIND_EXPERIMENTAL,
"%s can be declared with at most one of "
"DIAGNOSTIC, MANAGEABLE or EXPERIMENTAL", current->_name);
assert((flags & KIND_NOT_PRODUCT) == 0 &&
(flags & KIND_DEVELOP) == 0,
"%s has an optional DIAGNOSTIC, MANAGEABLE or EXPERIMENTAL "
"attribute; it must be declared as a product flag", current->_name);
}
}
}
coleenp
Apr 1, 2021
What's the difference between notproduct and develop again? Do we run tests with the optimized build and why would this flag be available in that build? ie. why not develop?
What's the difference between notproduct and develop again? Do we run tests with the optimized build and why would this flag be available in that build? ie. why not develop?
iklam
Apr 1, 2021
Author
Member
From the top of globals.hpp:
develop flags are settable / visible only during development and are constant in the PRODUCT versionnotproduct flags are settable / visible only during development and are not declared in the PRODUCT version
Since this flag is only used in test cases, and specifically for modifying its value, it doesn't make sense to expose this flag to the PRODUCT version at all. So I chose notproduct, so we can save a few bytes for the PRODUCT as well.
From the top of globals.hpp:
developflags are settable / visible only during development and are constant in the PRODUCT versionnotproductflags are settable / visible only during development and are not declared in the PRODUCT version
Since this flag is only used in test cases, and specifically for modifying its value, it doesn't make sense to expose this flag to the PRODUCT version at all. So I chose notproduct, so we can save a few bytes for the PRODUCT as well.
| // For example, DummyManageableStringFlag is needed because we don't | ||
| // have any MANAGEABLE flags of the ccstr type, but we really need to | ||
| // make sure the implementation is correct (in terms of memory allocation) | ||
| // just in case someone may add such a flag in the future. |
coleenp
Apr 1, 2021
What's the difference between notproduct and develop again? Do we run tests with the optimized build and why would this flag be available in that build? ie. why not develop?
What's the difference between notproduct and develop again? Do we run tests with the optimized build and why would this flag be available in that build? ie. why not develop?
This reverts commit 673aaaf.
| constraint) \ | ||
| \ | ||
| product(ccstr, DummyManageableStringFlag, NULL, MANAGEABLE, \ | ||
| "Dummy flag for testing string handling in WriteableFlags") \ |
coleenp
Apr 1, 2021
So this is in essence a product/manageable flag in debug only mode, which doesn't make sense at all, necessitating another macro that looks honestly bizarre. So I think that means a non-product manageable flag or even a develop manageable flag is something that we want, we want to be able to write a develop flag by the management interface. I agree diagnostic and experimental flags only seem to make sense as product flags.
The doc could simply be updated. Also the doc at the top of this file refers to CCC which is no longer -> CSR.
// MANAGEABLE flags are writeable external product flags.
// They are dynamically writeable through the JDK management interface
// (com.sun.management.HotSpotDiagnosticMXBean API) and also through JConsole.
// These flags are external exported interface (see CCC). The list of
// manageable flags can be queried programmatically through the management
// interface.
I'm not going to spend time typing about this minor point. The improvement is good and should be checked in.
So this is in essence a product/manageable flag in debug only mode, which doesn't make sense at all, necessitating another macro that looks honestly bizarre. So I think that means a non-product manageable flag or even a develop manageable flag is something that we want, we want to be able to write a develop flag by the management interface. I agree diagnostic and experimental flags only seem to make sense as product flags.
The doc could simply be updated. Also the doc at the top of this file refers to CCC which is no longer -> CSR.
// MANAGEABLE flags are writeable external product flags.
// They are dynamically writeable through the JDK management interface
// (com.sun.management.HotSpotDiagnosticMXBean API) and also through JConsole.
// These flags are external exported interface (see CCC). The list of
// manageable flags can be queried programmatically through the management
// interface.
I'm not going to spend time typing about this minor point. The improvement is good and should be checked in.
|
Thanks @coleenp and @dholmes-ora for reviewing. |
|
@iklam Since your change was applied there have been 2 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 5858399. |
|
Mailing list message from David Holmes on hotspot-dev: On 1/04/2021 3:29 pm, Ioi Lam wrote:
But the check was checking two things: 1. That diagnostic/manageable/experimental are mutually exclusive I believe both of these rules still stand based on what we defined such David
|
|
Mailing list message from David Holmes on jmx-dev: On 1/04/2021 5:05 am, Ioi Lam wrote:
Sorry but I don't understand how a test involving one flag replaces a David |
|
Mailing list message from Ioi Lam on jmx-dev: On 3/31/21 10:22 PM, David Holmes wrote:
When I did JDK-8243208, I wasn't sure if the VM would actually support Now that I have added such a flag, and I believe I have tested pretty Thanks
|
|
Mailing list message from Ioi Lam on hotspot-dev: On 3/31/21 10:47 PM, David Holmes wrote:
I think neither #1 and #2 make sense. These were limitation introduced ??? diagnostic(type, name, .... That's why you have #1 (mutual exclusion). #2 was also due to the implementation. It makes no sense that you can't However, in the old implementation, adding more variations would cause Anyway, changing this should be done in a separate RFE. I have reverted Thanks
|
|
Mailing list message from David Holmes on hotspot-dev: On 1/04/2021 4:19 pm, Ioi Lam wrote:
I don't agree with either of those claims. This is about semantics not David
|
There are two versions of JVMFlagAccess::ccstrAtPut() for modifying JVM flags of the ccstr type (i.e., strings).
We should combine these two versions into a single function, fix problems in the callers, and add test cases. The old value should be freed automatically, because typically the caller isn't interested in the old value.
Note that the FLAG_SET_XXX macros do not return the old value. Requiring the caller of FLAG_SET_XXX to free the old value would be tedious and error prone.
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/3254/head:pull/3254$ git checkout pull/3254Update a local copy of the PR:
$ git checkout pull/3254$ git pull https://git.openjdk.java.net/jdk pull/3254/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 3254View PR using the GUI difftool:
$ git pr show -t 3254Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/3254.diff