From coleenp at openjdk.java.net  Thu Apr  1 00:29:19 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 1 Apr 2021 00:29:19 GMT
Subject: jmx-dev RFR: 8264285: Clean the modification of ccstr JVM flags
 [v2]
In-Reply-To: <VvjLKxjUyItP6fpezKfYc9fIp-Ww2Mh8Bn_hjTCKlpc=.2e02a61c-089e-4a2c-a6d0-69d2e9ec6c09@github.com>
References: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
 <RfhOyilJToqc-vpjYA5jzD8OuQExhCznJ6ByNUEHEUU=.08409c9d-25b7-4fe4-b99b-66828d9acfc0@github.com>
 <VvjLKxjUyItP6fpezKfYc9fIp-Ww2Mh8Bn_hjTCKlpc=.2e02a61c-089e-4a2c-a6d0-69d2e9ec6c09@github.com>
Message-ID: <VISX-qQsNf_6pZZIYSaKKernXYWOtGh-btL3qZTE1ho=.c837d222-48e4-4e1a-99ee-fd3c1e4a6ece@github.com>

On Wed, 31 Mar 2021 19:02:02 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/runtime/flags/debug_globals.hpp line 38:
>> 
>>> 36: // have any MANAGEABLE flags of the ccstr type, but we really need to
>>> 37: // make sure the implementation is correct (in terms of memory allocation)
>>> 38: // just in case someone may add such a flag in the future.
>> 
>> Could you have just added a develop flag to the manageable flags instead?
>
> I had to use a `product` flag due to the following code, which should have been removed as part of [JDK-8243208](https://bugs.openjdk.java.net/browse/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);
>     }
>   }
> }

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?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3254

From coleenp at openjdk.java.net  Thu Apr  1 00:29:19 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 1 Apr 2021 00:29:19 GMT
Subject: jmx-dev RFR: 8264285: Clean the modification of ccstr JVM flags
 [v2]
In-Reply-To: <q7D70KR-QXTQttsny99SqkoimnZn-mvGGq0S_g3TlU4=.3ae2dde3-e69c-4c32-ac20-2490dcf0a034@github.com>
References: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
 <q7D70KR-QXTQttsny99SqkoimnZn-mvGGq0S_g3TlU4=.3ae2dde3-e69c-4c32-ac20-2490dcf0a034@github.com>
Message-ID: <JHiCCdyfKBAU0N-X5KihJjqt5qK7yz5fsU2aQdmatjc=.ae441cde-0901-4581-9f63-011bca06140b@github.com>

On Wed, 31 Mar 2021 19:01:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> There are two versions of JVMFlagAccess::ccstrAtPut() for modifying JVM flags of the ccstr type (i.e., strings).
>> 
>> - One version requires the caller to free the old value, but some callers don't do that (writeableFlags.cpp).
>> - The other version frees the old value on behalf of the caller. However, this version is accessible only via FLAG_SET_XXX macros and is currently unused. So it's unclear whether it actually works.
>> 
>> 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.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   relax flag attributions (ala JDK-7123237)

Marked as reviewed by coleenp (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3254

From iklam at openjdk.java.net  Thu Apr  1 04:31:26 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 1 Apr 2021 04:31:26 GMT
Subject: jmx-dev RFR: 8264285: Clean the modification of ccstr JVM flags
 [v2]
In-Reply-To: <VISX-qQsNf_6pZZIYSaKKernXYWOtGh-btL3qZTE1ho=.c837d222-48e4-4e1a-99ee-fd3c1e4a6ece@github.com>
References: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
 <RfhOyilJToqc-vpjYA5jzD8OuQExhCznJ6ByNUEHEUU=.08409c9d-25b7-4fe4-b99b-66828d9acfc0@github.com>
 <VvjLKxjUyItP6fpezKfYc9fIp-Ww2Mh8Bn_hjTCKlpc=.2e02a61c-089e-4a2c-a6d0-69d2e9ec6c09@github.com>
 <VISX-qQsNf_6pZZIYSaKKernXYWOtGh-btL3qZTE1ho=.c837d222-48e4-4e1a-99ee-fd3c1e4a6ece@github.com>
Message-ID: <qth0dWyYNNO7VotZ_6vgKbA2V9aic16bsdSJ9CLno6s=.ba18e5a0-87be-4352-946e-3d7a28c5f56f@github.com>

On Thu, 1 Apr 2021 00:25:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I had to use a `product` flag due to the following code, which should have been removed as part of [JDK-8243208](https://bugs.openjdk.java.net/browse/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);
>>     }
>>   }
>> }
>
> 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?

>From the top of globals.hpp: 

- `develop` flags are settable / visible only during development and are constant in the PRODUCT version
- `notproduct` 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.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3254

From david.holmes at oracle.com  Thu Apr  1 05:22:53 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 1 Apr 2021 15:22:53 +1000
Subject: jmx-dev RFR: 8264285: Clean the modification of ccstr JVM flags
 [v2]
In-Reply-To: <VvjLKxjUyItP6fpezKfYc9fIp-Ww2Mh8Bn_hjTCKlpc=.2e02a61c-089e-4a2c-a6d0-69d2e9ec6c09@github.com>
References: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
 <RfhOyilJToqc-vpjYA5jzD8OuQExhCznJ6ByNUEHEUU=.08409c9d-25b7-4fe4-b99b-66828d9acfc0@github.com>
 <VvjLKxjUyItP6fpezKfYc9fIp-Ww2Mh8Bn_hjTCKlpc=.2e02a61c-089e-4a2c-a6d0-69d2e9ec6c09@github.com>
Message-ID: <928358f3-5976-8e60-dbf2-c647d8fe3e02@oracle.com>

On 1/04/2021 5:05 am, Ioi Lam wrote:
> On Wed, 31 Mar 2021 12:58:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
> 
>>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    relax flag attributions (ala JDK-7123237)
>>
>> src/hotspot/share/runtime/flags/debug_globals.hpp line 38:
>>
>>> 36: // have any MANAGEABLE flags of the ccstr type, but we really need to
>>> 37: // make sure the implementation is correct (in terms of memory allocation)
>>> 38: // just in case someone may add such a flag in the future.
>>
>> Could you have just added a develop flag to the manageable flags instead?
> 
> I had to use a `product` flag due to the following code, which should have been removed as part of [JDK-8243208](https://bugs.openjdk.java.net/browse/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.

Sorry but I don't understand how a test involving one flag replaces a 
chunk of code that validated every flag declaration ??

David
-----

> 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);
>      }
>    }
> }
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3254
> 

From david.holmes at oracle.com  Thu Apr  1 05:47:48 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 1 Apr 2021 15:47:48 +1000
Subject: jmx-dev RFR: 8264285: Clean the modification of ccstr JVM flags
 [v2]
In-Reply-To: <8134d2f8-af9e-12ff-7381-62a91eeeec72@oracle.com>
References: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
 <RfhOyilJToqc-vpjYA5jzD8OuQExhCznJ6ByNUEHEUU=.08409c9d-25b7-4fe4-b99b-66828d9acfc0@github.com>
 <VvjLKxjUyItP6fpezKfYc9fIp-Ww2Mh8Bn_hjTCKlpc=.2e02a61c-089e-4a2c-a6d0-69d2e9ec6c09@github.com>
 <928358f3-5976-8e60-dbf2-c647d8fe3e02@oracle.com>
 <8134d2f8-af9e-12ff-7381-62a91eeeec72@oracle.com>
Message-ID: <56fca089-7f8b-1eff-e4cd-9eb1719c1c39@oracle.com>

On 1/04/2021 3:29 pm, Ioi Lam wrote:
> 
> 
> On 3/31/21 10:22 PM, David Holmes wrote:
>> On 1/04/2021 5:05 am, Ioi Lam wrote:
>>> On Wed, 31 Mar 2021 12:58:50 GMT, Coleen Phillimore 
>>> <coleenp at openjdk.org> wrote:
>>>
>>>>
>>>>> 36: // have any MANAGEABLE flags of the ccstr type, but we really 
>>>>> need to
>>>>> 37: // make sure the implementation is correct (in terms of memory 
>>>>> allocation)
>>>>> 38: // just in case someone may add such a flag in the future.
>>>>
>>>> Could you have just added a develop flag to the manageable flags 
>>>> instead?
>>>
>>> I had to use a `product` flag due to the following code, which should 
>>> have been removed as part of 
>>> [JDK-8243208](https://bugs.openjdk.java.net/browse/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.
>>
>> Sorry but I don't understand how a test involving one flag replaces a 
>> chunk of code that validated every flag declaration ??
>>
> 
> When I did JDK-8243208, I wasn't sure if the VM would actually support 
> diagnostic/manageable/experimental flags that were not `product`. So I 
> added check_all_flag_declarations() to prevent anyone from adding such a 
> flag "casually" without thinking about.
> 
> Now that I have added such a flag, and I believe I have tested pretty 
> thoroughly (tiers 1-4), I think the VM indeed supports these flags. So 
> now I feel it's safe to remove check_all_flag_declarations().

But the check was checking two things:

1. That diagnostic/manageable/experimental are mutually exclusive
2. That they only apply to product flags

I believe both of these rules still stand based on what we defined such 
attributes to mean. And even if you think #2 should not apply, #1 still 
does and so could still be checked. And if #2 is no longer our rule then 
the documentation in globals.hpp should be updated - though IMHO #2 
should remain as-is.

David
-----


> Thanks
> - Ioi
> 
> 
> 
>> David
>> -----
>>
>>> 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);
>>> ???? }
>>> ?? }
>>> }
>>>
>>> -------------
>>>
>>> PR: https://git.openjdk.java.net/jdk/pull/3254
>>>
> 

From iklam at openjdk.java.net  Thu Apr  1 06:08:52 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 1 Apr 2021 06:08:52 GMT
Subject: jmx-dev RFR: 8264285: Clean the modification of ccstr JVM flags
 [v3]
In-Reply-To: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
References: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
Message-ID: <eoboMgt2lP09azPLi40PLg5MiYcHqlVLDDQcPh4csbM=.a01a24f8-1b82-417e-9e29-ef9aa7395406@github.com>

> There are two versions of JVMFlagAccess::ccstrAtPut() for modifying JVM flags of the ccstr type (i.e., strings).
> 
> - One version requires the caller to free the old value, but some callers don't do that (writeableFlags.cpp).
> - The other version frees the old value on behalf of the caller. However, this version is accessible only via FLAG_SET_XXX macros and is currently unused. So it's unclear whether it actually works.
> 
> 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.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Revert "relax flag attributions (ala JDK-7123237)"
  
  This reverts commit 673aaafc4860dd7f70a3f222422ae84e85fd4219.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3254/files
  - new: https://git.openjdk.java.net/jdk/pull/3254/files/673aaafc..2a5e2b19

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3254&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3254&range=01-02

  Stats: 37 lines in 4 files changed: 36 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3254.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3254/head:pull/3254

PR: https://git.openjdk.java.net/jdk/pull/3254

From david.holmes at oracle.com  Thu Apr  1 06:35:59 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 1 Apr 2021 16:35:59 +1000
Subject: jmx-dev RFR: 8264285: Clean the modification of ccstr JVM flags
 [v2]
In-Reply-To: <ea85d8fc-4630-70cb-df1b-dc785ad8e420@oracle.com>
References: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
 <RfhOyilJToqc-vpjYA5jzD8OuQExhCznJ6ByNUEHEUU=.08409c9d-25b7-4fe4-b99b-66828d9acfc0@github.com>
 <VvjLKxjUyItP6fpezKfYc9fIp-Ww2Mh8Bn_hjTCKlpc=.2e02a61c-089e-4a2c-a6d0-69d2e9ec6c09@github.com>
 <928358f3-5976-8e60-dbf2-c647d8fe3e02@oracle.com>
 <8134d2f8-af9e-12ff-7381-62a91eeeec72@oracle.com>
 <56fca089-7f8b-1eff-e4cd-9eb1719c1c39@oracle.com>
 <ea85d8fc-4630-70cb-df1b-dc785ad8e420@oracle.com>
Message-ID: <131a0ea9-b491-f38e-d846-11af9db13897@oracle.com>

On 1/04/2021 4:19 pm, Ioi Lam wrote:
> 
> 
> On 3/31/21 10:47 PM, David Holmes wrote:
>> On 1/04/2021 3:29 pm, Ioi Lam wrote:
>>>
>>>
>>> On 3/31/21 10:22 PM, David Holmes wrote:
>>>> On 1/04/2021 5:05 am, Ioi Lam wrote:
>>>>> On Wed, 31 Mar 2021 12:58:50 GMT, Coleen Phillimore 
>>>>> <coleenp at openjdk.org> wrote:
>>>>>
>>>>>>
>>>>>>> 36: // have any MANAGEABLE flags of the ccstr type, but we really 
>>>>>>> need to
>>>>>>> 37: // make sure the implementation is correct (in terms of 
>>>>>>> memory allocation)
>>>>>>> 38: // just in case someone may add such a flag in the future.
>>>>>>
>>>>>> Could you have just added a develop flag to the manageable flags 
>>>>>> instead?
>>>>>
>>>>> I had to use a `product` flag due to the following code, which 
>>>>> should have been removed as part of 
>>>>> [JDK-8243208](https://bugs.openjdk.java.net/browse/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.
>>>>
>>>> Sorry but I don't understand how a test involving one flag replaces 
>>>> a chunk of code that validated every flag declaration ??
>>>>
>>>
>>> When I did JDK-8243208, I wasn't sure if the VM would actually 
>>> support diagnostic/manageable/experimental flags that were not 
>>> `product`. So I added check_all_flag_declarations() to prevent anyone 
>>> from adding such a flag "casually" without thinking about.
>>>
>>> Now that I have added such a flag, and I believe I have tested pretty 
>>> thoroughly (tiers 1-4), I think the VM indeed supports these flags. 
>>> So now I feel it's safe to remove check_all_flag_declarations().
>>
>> But the check was checking two things:
>>
>> 1. That diagnostic/manageable/experimental are mutually exclusive
>> 2. That they only apply to product flags
>>
>> I believe both of these rules still stand based on what we defined 
>> such attributes to mean. And even if you think #2 should not apply, #1 
>> still does and so could still be checked. And if #2 is no longer our 
>> rule then the documentation in globals.hpp should be updated - though 
>> IMHO #2 should remain as-is.
>>
> 
> I think neither #1 and #2 make sense. These were limitation introduced 
> by the old flags implementation, where you had to declare a flag using 
> one of these macros
> 
>  ??? diagnostic(type, name, ....
>  ??? manageable(type, name, ....
>  ??? experimental(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 
> have an develop flag for an experimental feature.

I don't agree with either of those claims. This is about semantics not 
implementation. diagnostic/manageable/experimental are distinct kinds of 
product flags with different levels of "support" based on their intended 
use in the product. We don't need such distinctions with non-product 
flags because the level of "support" is all the same and all flags are 
equal.

David
-----

> However, in the old implementation, adding more variations would cause 
> macro explosion. See 
> https://github.com/openjdk/jdk/blame/7d8519fffe46b6b5139b3aa51b18fcf0249a9e14/src/hotspot/share/runtime/flags/jvmFlag.cpp#L776 
> 
> 
> Anyway, changing this should be done in a separate RFE. I have reverted 
> [v2] from this PR, so we are back to [v1].
> 
> Thanks
> - Ioi
> 
> 
>> David
>> -----
>>
>>
>>> Thanks
>>> - Ioi
>>>
>>>
>>>
>>>> David
>>>> -----
>>>>
>>>>> 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);
>>>>> ???? }
>>>>> ?? }
>>>>> }
>>>>>
>>>>> -------------
>>>>>
>>>>> PR: https://git.openjdk.java.net/jdk/pull/3254
>>>>>
>>>
> 

From ioi.lam at oracle.com  Thu Apr  1 05:29:59 2021
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 31 Mar 2021 22:29:59 -0700
Subject: jmx-dev RFR: 8264285: Clean the modification of ccstr JVM flags
 [v2]
In-Reply-To: <928358f3-5976-8e60-dbf2-c647d8fe3e02@oracle.com>
References: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
 <RfhOyilJToqc-vpjYA5jzD8OuQExhCznJ6ByNUEHEUU=.08409c9d-25b7-4fe4-b99b-66828d9acfc0@github.com>
 <VvjLKxjUyItP6fpezKfYc9fIp-Ww2Mh8Bn_hjTCKlpc=.2e02a61c-089e-4a2c-a6d0-69d2e9ec6c09@github.com>
 <928358f3-5976-8e60-dbf2-c647d8fe3e02@oracle.com>
Message-ID: <8134d2f8-af9e-12ff-7381-62a91eeeec72@oracle.com>



On 3/31/21 10:22 PM, David Holmes wrote:
> On 1/04/2021 5:05 am, Ioi Lam wrote:
>> On Wed, 31 Mar 2021 12:58:50 GMT, Coleen Phillimore 
>> <coleenp at openjdk.org> wrote:
>>
>>>
>>>> 36: // have any MANAGEABLE flags of the ccstr type, but we really 
>>>> need to
>>>> 37: // make sure the implementation is correct (in terms of memory 
>>>> allocation)
>>>> 38: // just in case someone may add such a flag in the future.
>>>
>>> Could you have just added a develop flag to the manageable flags 
>>> instead?
>>
>> I had to use a `product` flag due to the following code, which should 
>> have been removed as part of 
>> [JDK-8243208](https://bugs.openjdk.java.net/browse/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.
>
> Sorry but I don't understand how a test involving one flag replaces a 
> chunk of code that validated every flag declaration ??
>

When I did JDK-8243208, I wasn't sure if the VM would actually support 
diagnostic/manageable/experimental flags that were not `product`. So I 
added check_all_flag_declarations() to prevent anyone from adding such a 
flag "casually" without thinking about.

Now that I have added such a flag, and I believe I have tested pretty 
thoroughly (tiers 1-4), I think the VM indeed supports these flags. So 
now I feel it's safe to remove check_all_flag_declarations().

Thanks
- Ioi



> David
> -----
>
>> 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);
>> ???? }
>> ?? }
>> }
>>
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/3254
>>


From ioi.lam at oracle.com  Thu Apr  1 06:19:12 2021
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 31 Mar 2021 23:19:12 -0700
Subject: jmx-dev RFR: 8264285: Clean the modification of ccstr JVM flags
 [v2]
In-Reply-To: <56fca089-7f8b-1eff-e4cd-9eb1719c1c39@oracle.com>
References: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
 <RfhOyilJToqc-vpjYA5jzD8OuQExhCznJ6ByNUEHEUU=.08409c9d-25b7-4fe4-b99b-66828d9acfc0@github.com>
 <VvjLKxjUyItP6fpezKfYc9fIp-Ww2Mh8Bn_hjTCKlpc=.2e02a61c-089e-4a2c-a6d0-69d2e9ec6c09@github.com>
 <928358f3-5976-8e60-dbf2-c647d8fe3e02@oracle.com>
 <8134d2f8-af9e-12ff-7381-62a91eeeec72@oracle.com>
 <56fca089-7f8b-1eff-e4cd-9eb1719c1c39@oracle.com>
Message-ID: <ea85d8fc-4630-70cb-df1b-dc785ad8e420@oracle.com>



On 3/31/21 10:47 PM, David Holmes wrote:
> On 1/04/2021 3:29 pm, Ioi Lam wrote:
>>
>>
>> On 3/31/21 10:22 PM, David Holmes wrote:
>>> On 1/04/2021 5:05 am, Ioi Lam wrote:
>>>> On Wed, 31 Mar 2021 12:58:50 GMT, Coleen Phillimore 
>>>> <coleenp at openjdk.org> wrote:
>>>>
>>>>>
>>>>>> 36: // have any MANAGEABLE flags of the ccstr type, but we really 
>>>>>> need to
>>>>>> 37: // make sure the implementation is correct (in terms of 
>>>>>> memory allocation)
>>>>>> 38: // just in case someone may add such a flag in the future.
>>>>>
>>>>> Could you have just added a develop flag to the manageable flags 
>>>>> instead?
>>>>
>>>> I had to use a `product` flag due to the following code, which 
>>>> should have been removed as part of 
>>>> [JDK-8243208](https://bugs.openjdk.java.net/browse/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.
>>>
>>> Sorry but I don't understand how a test involving one flag replaces 
>>> a chunk of code that validated every flag declaration ??
>>>
>>
>> When I did JDK-8243208, I wasn't sure if the VM would actually 
>> support diagnostic/manageable/experimental flags that were not 
>> `product`. So I added check_all_flag_declarations() to prevent anyone 
>> from adding such a flag "casually" without thinking about.
>>
>> Now that I have added such a flag, and I believe I have tested pretty 
>> thoroughly (tiers 1-4), I think the VM indeed supports these flags. 
>> So now I feel it's safe to remove check_all_flag_declarations().
>
> But the check was checking two things:
>
> 1. That diagnostic/manageable/experimental are mutually exclusive
> 2. That they only apply to product flags
>
> I believe both of these rules still stand based on what we defined 
> such attributes to mean. And even if you think #2 should not apply, #1 
> still does and so could still be checked. And if #2 is no longer our 
> rule then the documentation in globals.hpp should be updated - though 
> IMHO #2 should remain as-is.
>

I think neither #1 and #2 make sense. These were limitation introduced 
by the old flags implementation, where you had to declare a flag using 
one of these macros

 ??? diagnostic(type, name, ....
 ??? manageable(type, name, ....
 ??? experimental(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 
have an develop flag for an experimental feature.

However, in the old implementation, adding more variations would cause 
macro explosion. See 
https://github.com/openjdk/jdk/blame/7d8519fffe46b6b5139b3aa51b18fcf0249a9e14/src/hotspot/share/runtime/flags/jvmFlag.cpp#L776

Anyway, changing this should be done in a separate RFE. I have reverted 
[v2] from this PR, so we are back to [v1].

Thanks
- Ioi


> David
> -----
>
>
>> Thanks
>> - Ioi
>>
>>
>>
>>> David
>>> -----
>>>
>>>> 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);
>>>> ???? }
>>>> ?? }
>>>> }
>>>>
>>>> -------------
>>>>
>>>> PR: https://git.openjdk.java.net/jdk/pull/3254
>>>>
>>


From coleenp at openjdk.java.net  Thu Apr  1 11:40:28 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 1 Apr 2021 11:40:28 GMT
Subject: jmx-dev RFR: 8264285: Clean the modification of ccstr JVM flags
 [v3]
In-Reply-To: <eoboMgt2lP09azPLi40PLg5MiYcHqlVLDDQcPh4csbM=.a01a24f8-1b82-417e-9e29-ef9aa7395406@github.com>
References: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
 <eoboMgt2lP09azPLi40PLg5MiYcHqlVLDDQcPh4csbM=.a01a24f8-1b82-417e-9e29-ef9aa7395406@github.com>
Message-ID: <PDYrInWK2aF2dsNLMwWbPRGU7hjB2l4hCg4bN2K_xTg=.bb411804-df61-4fd1-b7b5-2d38301777c2@github.com>

On Thu, 1 Apr 2021 06:08:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> There are two versions of JVMFlagAccess::ccstrAtPut() for modifying JVM flags of the ccstr type (i.e., strings).
>> 
>> - One version requires the caller to free the old value, but some callers don't do that (writeableFlags.cpp).
>> - The other version frees the old value on behalf of the caller. However, this version is accessible only via FLAG_SET_XXX macros and is currently unused. So it's unclear whether it actually works.
>> 
>> 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.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "relax flag attributions (ala JDK-7123237)"
>   
>   This reverts commit 673aaafc4860dd7f70a3f222422ae84e85fd4219.

src/hotspot/share/runtime/flags/debug_globals.hpp line 63:

> 61:                                                                             \
> 62:   product(ccstr, DummyManageableStringFlag, NULL, MANAGEABLE,               \
> 63:           "Dummy flag for testing string handling in WriteableFlags")       \

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.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3254

From iklam at openjdk.java.net  Thu Apr  1 15:27:54 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 1 Apr 2021 15:27:54 GMT
Subject: jmx-dev RFR: 8264285: Clean the modification of ccstr JVM flags
 [v4]
In-Reply-To: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
References: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
Message-ID: <FfAKxxkoulN_OkNbhkILI-vVH7jFbGINDiDV_qsG0w8=.86d91e59-472d-4e24-9d60-900b0af46346@github.com>

> There are two versions of JVMFlagAccess::ccstrAtPut() for modifying JVM flags of the ccstr type (i.e., strings).
> 
> - One version requires the caller to free the old value, but some callers don't do that (writeableFlags.cpp).
> - The other version frees the old value on behalf of the caller. However, this version is accessible only via FLAG_SET_XXX macros and is currently unused. So it's unclear whether it actually works.
> 
> 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.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into 8264285-clean-up-setting-ccstr-jvm-flags
 - Revert "relax flag attributions (ala JDK-7123237)"
   
   This reverts commit 673aaafc4860dd7f70a3f222422ae84e85fd4219.
 - relax flag attributions (ala JDK-7123237)
 - restored SET_FLAG_XXX for ccstr type, and fixed bugs in existing ccstr modification code
 - 8264285: Do not support FLAG_SET_XXX for VM flags of string type

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3254/files
  - new: https://git.openjdk.java.net/jdk/pull/3254/files/2a5e2b19..5f912221

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3254&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3254&range=02-03

  Stats: 8053 lines in 376 files changed: 5492 ins; 1012 del; 1549 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3254.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3254/head:pull/3254

PR: https://git.openjdk.java.net/jdk/pull/3254

From iklam at openjdk.java.net  Thu Apr  1 18:28:24 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 1 Apr 2021 18:28:24 GMT
Subject: jmx-dev Integrated: 8264285: Clean the modification of ccstr JVM
 flags
In-Reply-To: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
References: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
Message-ID: <ksRtu5sevec0_O2aNYRX38Q-XnpzjeRcHB2mLQm1tgo=.7da0b4b3-272b-4c72-8574-e91218a58498@github.com>

On Mon, 29 Mar 2021 21:35:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> There are two versions of JVMFlagAccess::ccstrAtPut() for modifying JVM flags of the ccstr type (i.e., strings).
> 
> - One version requires the caller to free the old value, but some callers don't do that (writeableFlags.cpp).
> - The other version frees the old value on behalf of the caller. However, this version is accessible only via FLAG_SET_XXX macros and is currently unused. So it's unclear whether it actually works.
> 
> 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.

This pull request has now been integrated.

Changeset: 58583990
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/58583990
Stats:     205 lines in 9 files changed: 160 ins; 24 del; 21 mod

8264285: Clean the modification of ccstr JVM flags

Reviewed-by: dholmes, coleenp

-------------

PR: https://git.openjdk.java.net/jdk/pull/3254

From iklam at openjdk.java.net  Thu Apr  1 18:28:22 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 1 Apr 2021 18:28:22 GMT
Subject: jmx-dev RFR: 8264285: Clean the modification of ccstr JVM flags
 [v2]
In-Reply-To: <JHiCCdyfKBAU0N-X5KihJjqt5qK7yz5fsU2aQdmatjc=.ae441cde-0901-4581-9f63-011bca06140b@github.com>
References: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
 <q7D70KR-QXTQttsny99SqkoimnZn-mvGGq0S_g3TlU4=.3ae2dde3-e69c-4c32-ac20-2490dcf0a034@github.com>
 <JHiCCdyfKBAU0N-X5KihJjqt5qK7yz5fsU2aQdmatjc=.ae441cde-0901-4581-9f63-011bca06140b@github.com>
Message-ID: <FW8-eyaf_EIUXDm5EzuxKepG37ZkqJkf43rdGaXMRM0=.f0b2e575-e388-460e-b445-71b267ebb556@github.com>

On Thu, 1 Apr 2021 00:25:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   relax flag attributions (ala JDK-7123237)
>
> Marked as reviewed by coleenp (Reviewer).

Thanks @coleenp and @dholmes-ora for reviewing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3254

From dfuchs at openjdk.java.net  Fri Apr  2 18:00:57 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 2 Apr 2021 18:00:57 GMT
Subject: jmx-dev RFR: 8264124: Update MXBean specification and
 implementation to extend mapping of CompositeType to records [v7]
In-Reply-To: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
Message-ID: <Phlv0NzGD0uwW1UJ_rtl842TtfJfigfYzbwoBFkeOZw=.ad4be2bf-6f31-411d-9432-2163a4251e93@github.com>

> This RFE proposes to extend the MXBean framework to define a mapping to records.
> 
> The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names.
> 
> With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this:
> 
> CompositeType(
>     "NamedNumber",                      // typeName
>     "NamedNumber",                      // description
>     new String[] {"number", "name"},    // itemNames
>     new String[] {"number", "name"},    // itemDescriptions
>     new OpenType[] {SimpleType.INTEGER,
>                     SimpleType.STRING}  // itemTypes
> );
> 
> The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation:
> 
> public class NamedNumber {
>     public int getNumber() {return number;}
>     public String getName() {return name;}
>     @ConstructorParameters({"number", "name"})
>     public NamedNumber(int number, String name) {
>         this.number = number;
>         this.name = name;
>     }
>     private final int number;
>     private final String name;
> }
> 
> And the equivalent with a record class: 
> 
> public record NamedNumber(int number, String name) {}

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - Merge
 - minor style issue
 - minor style issue
 - Integrated review feedback
 - Improved test
 - Moved mapping for records just before Mapping for MXBean interface; Improved test.
 - Merge branch 'master' into mxbeans-8264124
 - Minor tweaks. Improved test.
 - Merge branch 'master' into mxbeans-8264124
 - Integrated review feedback. Updated the section for Mapping to records.
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/5fe7d4c4...257a6ed8

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3201/files
  - new: https://git.openjdk.java.net/jdk/pull/3201/files/a624a763..257a6ed8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=05-06

  Stats: 5593 lines in 174 files changed: 3784 ins; 623 del; 1186 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3201.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3201/head:pull/3201

PR: https://git.openjdk.java.net/jdk/pull/3201

From dfuchs at openjdk.java.net  Thu Apr  8 09:29:30 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 8 Apr 2021 09:29:30 GMT
Subject: jmx-dev RFR: 8264124: Update MXBean specification and
 implementation to extend mapping of CompositeType to records [v6]
In-Reply-To: <T1CmwpTcj2TCC7KSDu_OU4SmgA1XoJONDwnJysyniy0=.462d05d2-5100-4ec3-a13e-4d6a44336950@github.com>
References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
 <-HFZga_QfdbwjZcwnYCmvWjaXEACUzdW3fd6D6BhX6I=.38ba198b-70e4-4682-a7f4-13965bb47162@github.com>
 <T1CmwpTcj2TCC7KSDu_OU4SmgA1XoJONDwnJysyniy0=.462d05d2-5100-4ec3-a13e-4d6a44336950@github.com>
Message-ID: <kk1S2IIPXYZa5Zpc3NrNXm_IRqy9juLDwZpqhUKxV2Q=.9a0297e6-6e35-4a74-a5ba-b5046b5dbaad@github.com>

On Wed, 31 Mar 2021 21:43:58 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - minor style issue
>>  - minor style issue
>
> Thanks for making the change.  The spec change looks good to me.

@mlchung @AlanBateman @ChrisHegarty  would you formally approve the fix? The CSR has been approved.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3201

From chegar at openjdk.java.net  Thu Apr  8 18:12:11 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 8 Apr 2021 18:12:11 GMT
Subject: jmx-dev RFR: 8264124: Update MXBean specification and
 implementation to extend mapping of CompositeType to records [v7]
In-Reply-To: <Phlv0NzGD0uwW1UJ_rtl842TtfJfigfYzbwoBFkeOZw=.ad4be2bf-6f31-411d-9432-2163a4251e93@github.com>
References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
 <Phlv0NzGD0uwW1UJ_rtl842TtfJfigfYzbwoBFkeOZw=.ad4be2bf-6f31-411d-9432-2163a4251e93@github.com>
Message-ID: <9ImJYOGw4hDnvWrf0i88q9Onu3G5N7XSuKOamTmQrb0=.6d77eae9-f75e-4fa7-9a59-5201b6720121@github.com>

On Fri, 2 Apr 2021 18:00:57 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This RFE proposes to extend the MXBean framework to define a mapping to records.
>> 
>> The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names.
>> 
>> With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this:
>> 
>> CompositeType(
>>     "NamedNumber",                      // typeName
>>     "NamedNumber",                      // description
>>     new String[] {"number", "name"},    // itemNames
>>     new String[] {"number", "name"},    // itemDescriptions
>>     new OpenType[] {SimpleType.INTEGER,
>>                     SimpleType.STRING}  // itemTypes
>> );
>> 
>> The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation:
>> 
>> public class NamedNumber {
>>     public int getNumber() {return number;}
>>     public String getName() {return name;}
>>     @ConstructorParameters({"number", "name"})
>>     public NamedNumber(int number, String name) {
>>         this.number = number;
>>         this.name = name;
>>     }
>>     private final int number;
>>     private final String name;
>> }
>> 
>> And the equivalent with a record class: 
>> 
>> public record NamedNumber(int number, String name) {}
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge
>  - minor style issue
>  - minor style issue
>  - Integrated review feedback
>  - Improved test
>  - Moved mapping for records just before Mapping for MXBean interface; Improved test.
>  - Merge branch 'master' into mxbeans-8264124
>  - Minor tweaks. Improved test.
>  - Merge branch 'master' into mxbeans-8264124
>  - Integrated review feedback. Updated the section for Mapping to records.
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/8181cfe8...257a6ed8

Marked as reviewed by chegar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3201

From mchung at openjdk.java.net  Thu Apr  8 22:06:28 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 8 Apr 2021 22:06:28 GMT
Subject: jmx-dev RFR: 8264124: Update MXBean specification and
 implementation to extend mapping of CompositeType to records [v7]
In-Reply-To: <Phlv0NzGD0uwW1UJ_rtl842TtfJfigfYzbwoBFkeOZw=.ad4be2bf-6f31-411d-9432-2163a4251e93@github.com>
References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
 <Phlv0NzGD0uwW1UJ_rtl842TtfJfigfYzbwoBFkeOZw=.ad4be2bf-6f31-411d-9432-2163a4251e93@github.com>
Message-ID: <PDjNnvUq24M_9kypEMXbHv9x0QY_l7XQBwpQKLJT0dk=.8a8d87de-fb35-4d10-89a0-e32531b5393d@github.com>

On Fri, 2 Apr 2021 18:00:57 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This RFE proposes to extend the MXBean framework to define a mapping to records.
>> 
>> The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names.
>> 
>> With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this:
>> 
>> CompositeType(
>>     "NamedNumber",                      // typeName
>>     "NamedNumber",                      // description
>>     new String[] {"number", "name"},    // itemNames
>>     new String[] {"number", "name"},    // itemDescriptions
>>     new OpenType[] {SimpleType.INTEGER,
>>                     SimpleType.STRING}  // itemTypes
>> );
>> 
>> The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation:
>> 
>> public class NamedNumber {
>>     public int getNumber() {return number;}
>>     public String getName() {return name;}
>>     @ConstructorParameters({"number", "name"})
>>     public NamedNumber(int number, String name) {
>>         this.number = number;
>>         this.name = name;
>>     }
>>     private final int number;
>>     private final String name;
>> }
>> 
>> And the equivalent with a record class: 
>> 
>> public record NamedNumber(int number, String name) {}
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge
>  - minor style issue
>  - minor style issue
>  - Integrated review feedback
>  - Improved test
>  - Moved mapping for records just before Mapping for MXBean interface; Improved test.
>  - Merge branch 'master' into mxbeans-8264124
>  - Minor tweaks. Improved test.
>  - Merge branch 'master' into mxbeans-8264124
>  - Integrated review feedback. Updated the section for Mapping to records.
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/522a6472...257a6ed8

This looks okay to me but I'm not that familiar with the existing implementation.  The test case covers the important cases.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3201

From alanb at openjdk.java.net  Sun Apr 11 13:37:03 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 11 Apr 2021 13:37:03 GMT
Subject: jmx-dev RFR: 8264124: Update MXBean specification and
 implementation to extend mapping of CompositeType to records [v7]
In-Reply-To: <Phlv0NzGD0uwW1UJ_rtl842TtfJfigfYzbwoBFkeOZw=.ad4be2bf-6f31-411d-9432-2163a4251e93@github.com>
References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
 <Phlv0NzGD0uwW1UJ_rtl842TtfJfigfYzbwoBFkeOZw=.ad4be2bf-6f31-411d-9432-2163a4251e93@github.com>
Message-ID: <JCCcQy85lj_1D-8gpAapXzNrj6KlCa1Hx98_yL-WYFE=.0fee6d96-f4d1-463f-84a0-badbc53d8cbd@github.com>

On Fri, 2 Apr 2021 18:00:57 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This RFE proposes to extend the MXBean framework to define a mapping to records.
>> 
>> The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names.
>> 
>> With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this:
>> 
>> CompositeType(
>>     "NamedNumber",                      // typeName
>>     "NamedNumber",                      // description
>>     new String[] {"number", "name"},    // itemNames
>>     new String[] {"number", "name"},    // itemDescriptions
>>     new OpenType[] {SimpleType.INTEGER,
>>                     SimpleType.STRING}  // itemTypes
>> );
>> 
>> The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation:
>> 
>> public class NamedNumber {
>>     public int getNumber() {return number;}
>>     public String getName() {return name;}
>>     @ConstructorParameters({"number", "name"})
>>     public NamedNumber(int number, String name) {
>>         this.number = number;
>>         this.name = name;
>>     }
>>     private final int number;
>>     private final String name;
>> }
>> 
>> And the equivalent with a record class: 
>> 
>> public record NamedNumber(int number, String name) {}
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge
>  - minor style issue
>  - minor style issue
>  - Integrated review feedback
>  - Improved test
>  - Moved mapping for records just before Mapping for MXBean interface; Improved test.
>  - Merge branch 'master' into mxbeans-8264124
>  - Minor tweaks. Improved test.
>  - Merge branch 'master' into mxbeans-8264124
>  - Integrated review feedback. Updated the section for Mapping to records.
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/49d8cb13...257a6ed8

Spec and implementation changes look good.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3201

From dfuchs at openjdk.java.net  Mon Apr 12 16:34:38 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 12 Apr 2021 16:34:38 GMT
Subject: jmx-dev Integrated: 8264124: Update MXBean specification and
 implementation to extend mapping of CompositeType to records
In-Reply-To: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
Message-ID: <WEMMmh32ugrbiqt5VPP0CoxhGxpTyPJEaDme4NhBXjw=.d9bff65b-e3d8-4cc5-9a20-155ecd99b769@github.com>

On Thu, 25 Mar 2021 17:30:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> This RFE proposes to extend the MXBean framework to define a mapping to records.
> 
> The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names.
> 
> With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this:
> 
> 
> CompositeType(
>     "NamedNumber",                      // typeName
>     "NamedNumber",                      // description
>     new String[] {"number", "name"},    // itemNames
>     new String[] {"number", "name"},    // itemDescriptions
>     new OpenType[] {SimpleType.INTEGER,
>                     SimpleType.STRING}  // itemTypes
> );
> 
> 
> The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation:
> 
> 
> public class NamedNumber {
>     public int getNumber() {return number;}
>     public String getName() {return name;}
>     @ConstructorParameters({"number", "name"})
>     public NamedNumber(int number, String name) {
>         this.number = number;
>         this.name = name;
>     }
>     private final int number;
>     private final String name;
> }
> 
> 
> And the equivalent with a record class: 
> 
> 
> public record NamedNumber(int number, String name) {}

This pull request has now been integrated.

Changeset: d84a7e55
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d84a7e55
Stats:     872 lines in 3 files changed: 838 ins; 12 del; 22 mod

8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records

Reviewed-by: mchung, chegar, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/3201

From ysuenaga at openjdk.java.net  Tue Apr 13 05:01:33 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 13 Apr 2021 05:01:33 GMT
Subject: jmx-dev RFR: 8265104: CpuLoad and SystemCpuLoad in OperatingSystem
 MXBean returns -1.0
Message-ID: <OYebQCf7Bn5M-M-ZnYg-gZ57Q2fVCHicgkKgvtpku5o=.acd4021d-5b9d-4cda-984d-287111823e05@github.com>

I got -1.0 from both CpuLoad and SystemCpuLoad in OperatingSystem MXBean when I run the application on Fedora 33 x64 which is installed cgroups V2.

![jconsole-cpuload](https://user-images.githubusercontent.com/7421132/114485721-6372a180-9c47-11eb-81d9-568324cba336.png)

I do not run the application in the container, nor do not run with resource limitation on cgroups, so JMX should report CPU load on host value in this case.

-------------

Commit messages:
 - 8265104: CpuLoad and SystemCpuLoad in OperatingSystem MXBean returns -1.0

Changes: https://git.openjdk.java.net/jdk/pull/3447/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3447&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265104
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3447.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3447/head:pull/3447

PR: https://git.openjdk.java.net/jdk/pull/3447

From dholmes at openjdk.java.net  Tue Apr 13 06:17:58 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 13 Apr 2021 06:17:58 GMT
Subject: jmx-dev RFR: 8265104: CpuLoad and SystemCpuLoad in
 OperatingSystem MXBean returns -1.0
In-Reply-To: <OYebQCf7Bn5M-M-ZnYg-gZ57Q2fVCHicgkKgvtpku5o=.acd4021d-5b9d-4cda-984d-287111823e05@github.com>
References: <OYebQCf7Bn5M-M-ZnYg-gZ57Q2fVCHicgkKgvtpku5o=.acd4021d-5b9d-4cda-984d-287111823e05@github.com>
Message-ID: <-chfpbpw3z4u7MGrFp-XW0tyC1nStcvFQv33QkXLE64=.8f358a60-a6db-4ed7-888e-4176005f1ee8@github.com>

On Tue, 13 Apr 2021 02:00:24 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I got -1.0 from both CpuLoad and SystemCpuLoad in OperatingSystem MXBean when I run the application on Fedora 33 x64 which is installed cgroups V2.
> 
> ![jconsole-cpuload](https://user-images.githubusercontent.com/7421132/114485721-6372a180-9c47-11eb-81d9-568324cba336.png)
> 
> I do not run the application in the container, nor do not run with resource limitation on cgroups, so JMX should report CPU load on host value in this case.

Hi Yasumasa,

This strikes me as the wrong fix to the problem. isCpuSetSameAsHostCpuSet is only intended to be used as a simple optimization when the configured cpuset happens to match the hosts. What you are looking for is a fix to the problem when there is no cpuset set at all. It strikes me that in getCpuLoad() if there are no quotas and no effective-cpu-set and no cpusets.cpus value, then it should fallback to using the host values rather than returning -1. That said, the problem may also be that we have a containerMetrics object when no container is actually active! Perhaps that is the true bug here?

Thanks,
David

David

-------------

PR: https://git.openjdk.java.net/jdk/pull/3447

From ysuenaga at openjdk.java.net  Tue Apr 13 06:55:20 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 13 Apr 2021 06:55:20 GMT
Subject: jmx-dev RFR: 8265104: CpuLoad and SystemCpuLoad in
 OperatingSystem MXBean returns -1.0 [v2]
In-Reply-To: <OYebQCf7Bn5M-M-ZnYg-gZ57Q2fVCHicgkKgvtpku5o=.acd4021d-5b9d-4cda-984d-287111823e05@github.com>
References: <OYebQCf7Bn5M-M-ZnYg-gZ57Q2fVCHicgkKgvtpku5o=.acd4021d-5b9d-4cda-984d-287111823e05@github.com>
Message-ID: <apYs39cDbpnvvoY3ZoVfEXIGRdrer20cUeHpX-OvsRE=.e1300309-e7b2-406e-936f-27f0f8ab5e12@github.com>

> I got -1.0 from both CpuLoad and SystemCpuLoad in OperatingSystem MXBean when I run the application on Fedora 33 x64 which is installed cgroups V2.
> 
> ![jconsole-cpuload](https://user-images.githubusercontent.com/7421132/114485721-6372a180-9c47-11eb-81d9-568324cba336.png)
> 
> I do not run the application in the container, nor do not run with resource limitation on cgroups, so JMX should report CPU load on host value in this case.

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Return host CPU load directly from getCpuLoad()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3447/files
  - new: https://git.openjdk.java.net/jdk/pull/3447/files/f01564f3..8123fb36

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3447&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3447&range=00-01

  Stats: 7 lines in 1 file changed: 4 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3447.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3447/head:pull/3447

PR: https://git.openjdk.java.net/jdk/pull/3447

From ysuenaga at openjdk.java.net  Tue Apr 13 07:03:04 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 13 Apr 2021 07:03:04 GMT
Subject: jmx-dev RFR: 8265104: CpuLoad and SystemCpuLoad in
 OperatingSystem MXBean returns -1.0 [v2]
In-Reply-To: <-chfpbpw3z4u7MGrFp-XW0tyC1nStcvFQv33QkXLE64=.8f358a60-a6db-4ed7-888e-4176005f1ee8@github.com>
References: <OYebQCf7Bn5M-M-ZnYg-gZ57Q2fVCHicgkKgvtpku5o=.acd4021d-5b9d-4cda-984d-287111823e05@github.com>
 <-chfpbpw3z4u7MGrFp-XW0tyC1nStcvFQv33QkXLE64=.8f358a60-a6db-4ed7-888e-4176005f1ee8@github.com>
Message-ID: <BLQy-K8Y7X4952jBHrI7Btb9BN2xMqK26NthcJAD5Ms=.31c32814-b537-422a-8c83-888a93500191@github.com>

On Tue, 13 Apr 2021 06:14:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This strikes me as the wrong fix to the problem. isCpuSetSameAsHostCpuSet is only intended to be used as a simple optimization when the configured cpuset happens to match the hosts. What you are looking for is a fix to the problem when there is no cpuset set at all.

I pushed new commit to move the fix into `getCpuLoad()`.

> It strikes me that in getCpuLoad() if there are no quotas and no effective-cpu-set and no cpusets.cpus value, then it should fallback to using the host values rather than returning -1. That said, the problem may also be that we have a containerMetrics object when no container is actually active! Perhaps that is the true bug here?

I think this problem is similar to [JDK-8264482](https://bugs.openjdk.java.net/browse/JDK-8264482) (PR #3280 ). Currently both HotSpot and MBean check whether cgroups exists, but the the host (not into the container) might have it. We've discussed about it in #3280 , then I think it is difficult to modify to check whether the VM is in the container. Thus I think it is reasonable to just return host CPU load value at here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3447

From sgehwolf at openjdk.java.net  Tue Apr 13 14:27:00 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 13 Apr 2021 14:27:00 GMT
Subject: jmx-dev RFR: 8265104: CpuLoad and SystemCpuLoad in
 OperatingSystem MXBean returns -1.0 [v2]
In-Reply-To: <apYs39cDbpnvvoY3ZoVfEXIGRdrer20cUeHpX-OvsRE=.e1300309-e7b2-406e-936f-27f0f8ab5e12@github.com>
References: <OYebQCf7Bn5M-M-ZnYg-gZ57Q2fVCHicgkKgvtpku5o=.acd4021d-5b9d-4cda-984d-287111823e05@github.com>
 <apYs39cDbpnvvoY3ZoVfEXIGRdrer20cUeHpX-OvsRE=.e1300309-e7b2-406e-936f-27f0f8ab5e12@github.com>
Message-ID: <_jJIKCWXPW0oO7y40HkRdDtbs-0OABS9rHAcf_M3qbo=.541bb951-9c7a-4f8d-80b4-718643a4fa4b@github.com>

On Tue, 13 Apr 2021 06:55:20 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I got -1.0 from both CpuLoad and SystemCpuLoad in OperatingSystem MXBean when I run the application on Fedora 33 x64 which is installed cgroups V2.
>> 
>> ![jconsole-cpuload](https://user-images.githubusercontent.com/7421132/114485721-6372a180-9c47-11eb-81d9-568324cba336.png)
>> 
>> I do not run the application in the container, nor do not run with resource limitation on cgroups, so JMX should report CPU load on host value in this case.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Return host CPU load directly from getCpuLoad()

This looks reasonable to me.

-------------

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3447

From dholmes at openjdk.java.net  Wed Apr 14 02:53:59 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 14 Apr 2021 02:53:59 GMT
Subject: jmx-dev RFR: 8265104: CpuLoad and SystemCpuLoad in
 OperatingSystem MXBean returns -1.0 [v2]
In-Reply-To: <apYs39cDbpnvvoY3ZoVfEXIGRdrer20cUeHpX-OvsRE=.e1300309-e7b2-406e-936f-27f0f8ab5e12@github.com>
References: <OYebQCf7Bn5M-M-ZnYg-gZ57Q2fVCHicgkKgvtpku5o=.acd4021d-5b9d-4cda-984d-287111823e05@github.com>
 <apYs39cDbpnvvoY3ZoVfEXIGRdrer20cUeHpX-OvsRE=.e1300309-e7b2-406e-936f-27f0f8ab5e12@github.com>
Message-ID: <ZyxW68aq9UJyprIA5YEddshl-FOitwKDZg5U3lZNYcc=.83255d23-a885-4ad2-b540-28d5d554b1bf@github.com>

On Tue, 13 Apr 2021 06:55:20 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I got -1.0 from both CpuLoad and SystemCpuLoad in OperatingSystem MXBean when I run the application on Fedora 33 x64 which is installed cgroups V2.
>> 
>> ![jconsole-cpuload](https://user-images.githubusercontent.com/7421132/114485721-6372a180-9c47-11eb-81d9-568324cba336.png)
>> 
>> I do not run the application in the container, nor do not run with resource limitation on cgroups, so JMX should report CPU load on host value in this case.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Return host CPU load directly from getCpuLoad()

Thanks Yasumasa, this seems a much better approach.

David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3447

From ysuenaga at openjdk.java.net  Wed Apr 14 07:41:58 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 14 Apr 2021 07:41:58 GMT
Subject: jmx-dev Integrated: 8265104: CpuLoad and SystemCpuLoad in
 OperatingSystem MXBean returns -1.0
In-Reply-To: <OYebQCf7Bn5M-M-ZnYg-gZ57Q2fVCHicgkKgvtpku5o=.acd4021d-5b9d-4cda-984d-287111823e05@github.com>
References: <OYebQCf7Bn5M-M-ZnYg-gZ57Q2fVCHicgkKgvtpku5o=.acd4021d-5b9d-4cda-984d-287111823e05@github.com>
Message-ID: <5KgtEP_CZzJjp2Qbq1K9fhS1uQtWM0kQPHEon90QoJw=.97b4bf87-c366-4030-bb89-6ad4892ab541@github.com>

On Tue, 13 Apr 2021 02:00:24 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I got -1.0 from both CpuLoad and SystemCpuLoad in OperatingSystem MXBean when I run the application on Fedora 33 x64 which is installed cgroups V2.
> 
> ![jconsole-cpuload](https://user-images.githubusercontent.com/7421132/114485721-6372a180-9c47-11eb-81d9-568324cba336.png)
> 
> I do not run the application in the container, nor do not run with resource limitation on cgroups, so JMX should report CPU load on host value in this case.

This pull request has now been integrated.

Changeset: e2106d5a
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e2106d5a
Stats:     6 lines in 1 file changed: 4 ins; 0 del; 2 mod

8265104: CpuLoad and SystemCpuLoad in OperatingSystem MXBean returns -1.0

Reviewed-by: dholmes, sgehwolf

-------------

PR: https://git.openjdk.java.net/jdk/pull/3447