On Tue, 17 Sep 2024 09:24:12 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
>> Sorry if I'm holding this up. The reasoning did get confusing to me. >> >> We are not always good at documenting these commands. But at some point, >> somebody among us will hopefully document them, or explain it to somebody >> who will. There will need to be explanation of how the outputs differ on >> Linux and Windows, and how the information can be used. >> >> RSS is on Linux only... No problem, that has a well-understood meaning on >> *nix systems. >> >> offset? It's the same as the size of the previous line of output. Or the >> sum of sizes if there are multiple lines as part of the same allocation. >> It's Windows only. It's not likely this is more useful on Windows than >> Linux. Is it considered missing on Linux, or just not needed? > >> Sorry if I'm holding this up. The reasoning did get confusing to me. >> >> We are not always good at documenting these commands. But at some point, >> somebody among us will hopefully document them, or explain it to somebody >> who will. There will need to be explanation of how the outputs differ on >> Linux and Windows, and how the information can be used. >> >> RSS is on Linux only... No problem, that has a well-understood meaning on >> *nix systems. >> >> offset? It's the same as the size of the previous line of output. Or the sum >> of sizes if there are multiple lines as part of the same allocation. It's >> Windows only. It's not likely this is more useful on Windows than Linux. Is >> it considered missing on Linux, or just not needed? > > A general note, this is an OS-specific tool. There will be overlapping > between OSes, but it is understood that the analyst knows the idiosyncrasies > of the target OS' memory management. We should not try to generalize, and we > should use OS specific terms. > > So, RSS makes sense in Linux. On Windows, a roughly corresponding term would > be WorkingSetSize, but we don't get on a per-mapping base. > > What Simon prints as "offset" is the distance to the allocation base, aka the > start of the memory region allocated with VirtualAlloc. It's a two-layer > system, with the kernel keeping track of both committed/uncommitted regions > as well as the underlying allocations. That concept does not exist on Linux > at the kernel level. > > Offset is good to know since one can see where an allocation started (offset > 0). I would add a short text in the legend, since it is easily confused with > file offset for file mappings. >I agree the offset column isn't vital, but the start of allocation may be (at >some point, to someone), and, as @tstuefe commented, there is no equivalent on >Linux. The offset is good to know since it shows clearly what original VirtualAlloc allocation a committed section belongs to. E.g. all committed/uncommitted sections of the heap should refer in their offsets to the java heap. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20597#issuecomment-2357566580
