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

Thomas Stüfe thomas.stuefe at gmail.com
Fri Aug 30 05:54:36 UTC 2024


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/367b0de8/attachment.htm>


More information about the serviceability-dev mailing list