[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074 [v2]
From:       David Holmes <dholmes () openjdk ! org>
Date:       2023-07-27 7:14:56
Message-ID: qJo-9mQWvlngwl6M3FszE1zdeO5_0ii93kn7ZeI9qNc=.0a518f46-67ed-46d9-ba30-55f4045f2559 () github ! com
[Download RAW message or body]

On Wed, 26 Jul 2023 15:19:02 GMT, Paul Hohensee <phh@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

src/hotspot/share/services/management.cpp line 2119:

> 2117: 
> 2118:     {
> 2119:       assert(MonitoringSupport_lock != nullptr, "Must be");

This was unnecessary. If you have this here you would have one before every single \
use of mutex that is expected to be non-null.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15028#discussion_r1275828276


[prev in list] [next in list] [prev in thread] [next in thread]