RFR: 8319873: Add windows implementation for jcmd System.map and System.dump_map [v13]

[Thomas Stuefe]

On Tue, 17 Sep 2024 09:24:12 GMT, Thomas Stuefe <stuefe at 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