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

[Volker Simonis]

On Sun, 26 Nov 2023 19:54:02 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.

I didn't read the PR comment carefully (my fault :) so here's my list of changes with regards to the corresponding jdk11 change set (see https://github.com/openjdk/jdk11u-dev/pull/2286). I'll provide them here in the hope to simplify the review for others:

- in jdk8 we have two `jmm.h` files, one in `jdk/src/share/javavm/export/jmm.h` and one in `hotspot/src/share/vm/services/jmm.h`. The changes to both files are the same.
- There's no `HotSpotThreadImpl.java` so the function added in the base class `ThreadImpl.java` has to be public in jdk8u.
- there is no `jdk/make/mapfiles/libmanagement/mapfile-vers` in `jdk11u` and later.
- there's no `JavaThreadIteratorWithHandle`/`ThreadsListHandle` in jdk8 that's why we have to use the `Threads_lock` while iterating over the threads. It's also the reason why parts of the comments in `jmm_GetTotalThreadAllocatedMemory()` became obsolete and have been removed.

@phohensee, is my assumption correct that you also use this already in production within Amazon and haven't seen any negative impact (particularly not due to the usage of the `Threads_lock` in `jmm_GetTotalThreadAllocatedMemory()` ?

jdk/make/mapfiles/libmanagement/mapfile-vers line 92:

> 90: 	    Java_sun_management_ThreadImpl_getThreadAllocatedMemory0;
> 91: 	    Java_sun_management_ThreadImpl_getThreadAllocatedMemory1;
> 92:             Java_sun_management_ThreadImpl_getTotalThreadAllocatedMemory;

All the other entries are indented by a TAB plus four spaces. This is not ideal, but please use the same scheme to get the same indentation independently of the TAB size.

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

Changes requested by simonis (Reviewer).

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