Splitting NMT memory counters into "live" and "flat" classes

[Robert Toyonaga]

Yes, I guess we could get rid of atomics for VirtualMemory since we lock
anyway in order to update the internal memory model.

 In that case, maybe it only makes sense to split MemoryCounter into “live”
and “flat” classes, since VirtualMemory will effectively be flat anyway.

Thanks!
Robert Toyonaga

On Fri, Aug 30, 2024 at 1:54 AM Thomas Stüfe <thomas.stuefe at gmail.com>
wrote:

> My current thinking (which may change) is that for VirtualMemory, we may
> not need atomic counters at all since these counters are used in
> conjunction with modifying the not lock-free virtual memory tracker.
>
> For malloc counters, this makes sense, since all we do for malloc is to
> increase these counters (in summary mode) and in detail mode, we add the
> call site to the malloc site table, which is lock free.
>
> Cheers, Thomas
>
>
>
> On Thu, Aug 29, 2024 at 5:30 PM Robert Toyonaga <rtoyonag at redhat.com>
> wrote:
>
>> Hi Everyone,
>>
>> What are your thoughts on splitting the NMT memory counter classes (both
>> MemoryCounter and VirtualMemory) into "live" and "flat" classes? Currently,
>> the counters are used for both recording live data and for storing static
>> data when creating reports. However, after snapshotting the counters for
>> report generation, we no longer need atomic operations or any updating of
>> peak values. The "live" set of classes could keep the atomic operations,
>> peak updating, setters, and snapshotting functionality. The "flat" classes
>> could get rid of atomic, peak updating, and only need getters.
>>
>> The JBS issue for this is JDK-8334234
>>
>> Thanks!
>> Robert Toyonaga
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240830/600188dc/attachment.htm>