On Tue, 12 May 2026 07:02:10 GMT, Stefan Karlsson <[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? I like `resident_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. yes, but that is a bigger problem and pre-existing (though worth solving). Historically, NMT always reported committed ranges, except for thread stacks, which we counted by checking what was live/resident in the thread stack. One has to know this when looking at NMT output. One of NMT's many charms, I guess. For thread stacks, we needed to do this because otherwise we would have counted them as fully committed, which would have confused everyone. The same argument can be made for all the other memory mappings in the process, but the argument usually was that we only commit what we plan to use shortly, so the number are not too terribly off. But then, maybe they are :-D. E.g. if you use Xmx==Xms. There is a long-standing bug open by @simonis (https://bugs.openjdk.org/browse/JDK-8249666) to add actual residency numbers to NMT. I never had the time to do this so far. Obviously, one of the main issues would be cost, but it could be optional in NMT reports. And another issue is that NMT reporting code is already bloated as it is; simplifications would probably be in order beforehand. 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? ------------- PR Comment: https://git.openjdk.org/jdk/pull/31124#issuecomment-4495997991
