RFR: 8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074 [v2]

Aleksey Shipilev shade at openjdk.org
Wed Jul 26 15:29:40 UTC 2023


On Wed, 26 Jul 2023 15:19:02 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> MonitoringSupport_lock is initialized only when UseG1GC is true, but [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to implement getTotalThreadAllocatedBytes, which is available for all garbage collectors. While the current code sets UseG1GC regardless of which collector is specified, see FLAG_SET_ERGO_IF_DEFAULT(UseG1GC, true) in gcConfig.cpp, if G1 isn't included in the Hotspot build or Hotspot is not running on a server class machine (unlikely these days), the lock will not be initialized. The lock's initialization should be unconditional.
>> 
>> I updated ThreadAllocatedMemory.java to run the test using both G1 and Serial collectors.
>
> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074

Looks good! I reverted the `mutexLocker.cpp` hunk locally, and the test fails on assert, as expected.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15028#pullrequestreview-1548033607


More information about the serviceability-dev mailing list