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

[Paul Hohensee]

On Mon, 8 May 2023 02:07:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Afaiu, SMR/TLH keeps a terminated thread's TLS accessible, but doesn't stop the termination process.
>> 
>> If we initialize result with exited_allocated_bytes, the "too small" possibility is still there. We still have a window between that initialization and the creation of the threads iterator where threads may terminate and thus not be included in the iteration. And new threads may become active during the iteration and not be included. As Aleksey observes, an advantage is that threads that terminate during the iteration will be counted only once and we don't have to check for terminated threads.
>> 
>> If we stick with adding exited_allocated_bytes to result after the iteration, Volker is correct that we shouldn't include terminated threads in the sum because their allocated bytes values will have been added to exited_allocated_bytes. We have the same undercount possibility that initializing result with exited_allocated_bytes has, so this (fixed) approach can result in "too small" also, but "too large" goes away.
>> 
>> Looks like both approaches are equivalent, so let's go with initializing result with exited_allocated_bytes because it avoids a comparison in the loop.
>
>> Afaiu, SMR/TLH keeps a terminated thread's TLS accessible, but doesn't stop the termination process.
> 
> Incorrect. A thread cannot complete the termination process if it is contained by a TLH - see ` ThreadsSMRSupport::smr_delete` and the call to `wait_until_not_protected`.
> 
> But not sure that helps with the zero-else-double accounting problem. Any read of the "total accumulated bytes written to date" value is racing with terminating threads.

Resolved, see below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1192494925