[jdk8u-dev] RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v2]

[Andrew John Hughes]

On Tue, 28 Nov 2023 23:14:29 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> I'd like to backport the definition and implementation of com.sun.management.ThreadMXBean.getTotalThreadAllocatedBytes to 8u. The backport CSR is [JDK-8320375](https://bugs.openjdk.org/browse/JDK-8320375). A follow-up bugfix backport of [JDK-8313081](https://bugs.openjdk.org/browse/JDK-8313081) will be done following this backport. The combined backports have been in production at Amazon for two months with no issues. The backport uses the reserved1 slot in jmm.h in order to preserve binary compatibility with 8u. Per current policy, there is no update to JMM_VERSION in jmm.h and the new method is marked
>> 
>> @since 8u412
>> 
>> Aside from file relocation and context differences, relative to the 11u backport the MonitoringSupport_lock definition macro changes, and the reserved1 rather than reserved6 jmm slot is used. SMR doesn't exist in 8u, so jmm_GetTotalThreadAllocated bytes attempts to lock Threads_lock instead, and if the Threads_lock is already locked, the previous return value is returned. HotSpotThreadImpl.java doesn't exist in 8u, so the hunk associated with it is dropped.
>
> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304074: whitespace fix

Thanks @simonis for your comments. It made these easier to review. Changes from 11u look fine.

@phohensee where is the 8u CSR? The only one I can find from the bug is the 21u CSR [JDK-8307396](https://bugs.openjdk.org/browse/JDK-8307396) and there seems to be no 8u backport issue.

Given we are a week out from rampdown for 8u412, and this change has not yet been released in 11u & 17u, I would suggest we integrate this after rampdown for 8u422.

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

Marked as reviewed by andrew (Reviewer).

PR Review: https://git.openjdk.org/jdk8u-dev/pull/392#pullrequestreview-1885854925