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

List:       openjdk-serviceability-dev
Subject:    Integrated: 8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074
From:       Paul Hohensee <phh () openjdk ! org>
Date:       2023-07-26 19:33:49
Message-ID: 94S7MWreF1CwP5D1GT0I8uWKBicTbYzjMooiYetFf5s=.3104053f-c9fc-4ca6-8a29-5492d36ff91b () github ! com
[Download RAW message or body]

On Tue, 25 Jul 2023 21:48:24 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.

This pull request has now been integrated.

Changeset: a9d21c61
Author:    Paul Hohensee <phh@openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a9d21c61fb12a11e18c6bb8aa903e5a8e42473f1
                
Stats:     17 lines in 3 files changed: 12 ins; 2 del; 3 mod

8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074

Reviewed-by: dholmes, sspitsyn, shade

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

PR: https://git.openjdk.org/jdk/pull/15028


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

Configure | About | News | Add a list | Sponsored by KoreLogic