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

Thomas Stuefe stuefe at openjdk.org
Wed Sep 18 06:01:11 UTC 2024


On Thu, 12 Sep 2024 20:10:45 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/16982072/sample_windows_map.txt)
>
> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove trailing whitespace

Still good. Ship it!

> Thanks Thomas - It's understood what the info is, main question was when is it useful, and do we need to differ from Linux.
> 
> Looking at 8318636: #16301 the Linux example linked in the introduction there shows an offset column.
> 
> Maybe Simon you're taking inspiration from that original, and there was an extension to the feature just over a month ago in 8322475: #17158
> 
> ...where the offset column was taken out. 8322475 also separated "info" and "file" into their own columns. Only CDS and one of the hsperfdata lines use both columns that I notice, but there may be others. Here in Windows we're going with one column for both, unlike the updated Linux format.
> 
> This PR is implementing "classic" System.map, not the "modern 2024" version? 8-)
> 

"offset" in the Linux version was the file offset of mapped files. We have only very few mapped files, most mappings are anonymous, and the offset is usually 0. I took it out to save horizontal space.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20597#pullrequestreview-2311693809
PR Comment: https://git.openjdk.org/jdk/pull/20597#issuecomment-2357568279


More information about the serviceability-dev mailing list