<div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Cheers, Thomas<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 29, 2024 at 5:30 PM Robert Toyonaga <<a href="mailto:rtoyonag@redhat.com">rtoyonag@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Everyone,<br><br>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.<br><br>The JBS issue for this is JDK-8334234<div><br>Thanks!<br>Robert Toyonaga<br></div></div>
</blockquote></div>