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 <rtoyo...@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 >
