On Tue, 12 May 2026 12:59:37 GMT, Robert Toyonaga <[email protected]> wrote:
>>> The name is misleading, it actually is meant to find live pages not just >>> committed pages >> >> Neither the mincore man pages nor the Windows the QueryWorkingSetEx talks >> about "live" pages. I don't think NMT or the rest of the JVM does either. >> This leads me to think that this terminology might not be the one we want. >> Also, if I see a call to `os::live_in_range` I don't know what that function >> is trying to convey. Is there a better name for the property we are looking >> for? >> >> Also, the NMT function that calls `os::live_in_range` is called >> `RegionIterator::next_committed`, so there's still a naming skew there, I >> think. > >> Is there a better name for the property we are looking for? > > How about something like `resident_in_range`, `physical_in_range`, or maybe > `working_set_in_range`? > >> Also, the NMT function that calls os::live_in_range is called >> `RegionIterator::next_committed`, so there's still a naming skew there, I >> think. > > That's a good point. Maybe it should be renamed as well based on whatever we > choose to rename `committed_in_range` to. >Question, @roberttoyonaga - before your patch, on Windows, NMT would have >reported the full thread stack size as committed? So, 1000 threads a 1mb = 1gb >committed thread stacks? Hi @tstuefe, thank you for your feedback! I experimented with a toy app on Windows that starts 1000 threads and used `-Xss1m -XX:NativeMemoryTracking=summary -XX:+UnlockDiagnosticVMOptions -XX:+PrintNMTStatistics`. Before this patch NMT shows: `stack: reserved=1072693248, committed=67051520, peak=67051520` After this patch NMT shows: `stack: reserved=1085276160, committed=17104896, peak=17104896` I repeated this a few times and the results were stable. So it seems like even before this patch, the committed memory reported by NMT is not the whole region reserved for thread stacks. This is good news because it at least shows the old accounting was not wildly inaccurate on Windows. But it still is very different than the actual resident size reported after this patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31124#issuecomment-4502208488
