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

[Kevin Walls]

On Wed, 11 Sep 2024 14:48:53 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> This is a port of [JDK-8318636](https://github.com/openjdk/jdk/pull/16301) to Windows.
>> 
>> System.map and System.dump_map are implemented using the Windows API and provide roughly the same information in the same format.  Most of the heavy lifting was implemented by @tstuefe in #16301 - this PR adds the Windows implementation and enables the common code for Windows 64 bit.
>>  
>> [Sample output (with NMT enabled)](https://github.com/user-attachments/files/16663332/vm_memory_map_760.txt)
>
> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes per review

Hi,
Great to bring up a Windows version of this.

Is the offset column useful?
It tells us whether a line is the start of an allocation (offset 0) or a continuation of one.  Maybe that is useful if there is no name from NMT?  I didn't yet notice one where it helped but maybe...

If it really is a useful column, is it possible to tweak the columns so the "JAVAHEAP" stays in line?

0x0000000706000000-0x0000000715a00000    262144000 rw--  c-pvt         0 JAVAHEAP 
0x0000000715a00000-0x00000007ffe00000   3930062848 ----  r-pvt 0xfa00000 JAVAHEAP 
0x00000007ffe00000-0x0000000800000000      2097152 rw--  c-pvt 0xf9e00000 JAVAHEAP 

Maybe the offset column is just too narrow, and the INDENT_BY(72) needs to be bigger, plus adjusting the header string?  Java heap seems to be the value that is likely to be largest here, so allowing more space would be good.


On Linux I see info and file have separate columns.  Here, "vm info/file" is the column?
Mostly I see there being either some info or a file, although CDS and classes.jsa is a line that has both. I like what you have here where it will print "CDS /path/classes.jsa" withouth using two columns. 8-)
If it were just called "info/file" then I couldn't think there was a "vm" column that had failed to print.

src/hotspot/os/windows/memMapPrinter_windows.cpp line 98:

> 96:       out.put('r');
> 97:     } else {
> 98:       fatal("Unknown Windows memory state value: 0x%x", mem_info.State);

Are these really fatal?  We don't want to risk ending the target process with a jcmd.  Maybe a warning, as part of the command output (not the JVM's stdout/err) if we want to say something?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20597#issuecomment-2343918276
PR Review Comment: https://git.openjdk.org/jdk/pull/20597#discussion_r1754860701