RFR: 8319875: Add macOS implementation for jcmd System.map [v2]

Thomas Stuefe stuefe at openjdk.org
Mon Nov 4 14:07:35 UTC 2024


On Tue, 29 Oct 2024 14:09:21 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> Looking good, small nits remain. Could you share an example output (maybe one run with G1, one with ZGC?)
>
>> Looking good, small nits remain. Could you share an example output (maybe one run with G1, one with ZGC?)
> 
> @tstuefe, Sample output for G1 and ZGC has been attached to the description (and I fixed the ZGC test)

Hi @stooke,

nice. There are some aspects about the output that is surprising, though. I expect reserved-only memory to be mapped with MAP_NORESERVE and no access rights. I expect committed memory to be mapped without MAP_NORESERVE and write- or executable access.

- (G1) I only see one segment for JAVAHEAP. I would expect at least two, one reserved-only, one reserved and committed. Or did you precommit the heap (start JVM with -Xmx==-Xms)? Can you please test that with ParallelGC and without specifying Xms, we should see four java heap mappings side by side, for young and old gen, each with a committed part (rw) and a reserved part (not accessible). Like we do now for the CODE section. Please also countercheck that the address ranges are correct against the heap range (easiest, run jcmd .. VM.info and look for the Heap section, it tells you the address ranges).
- The 64K META and CLASS blocks confuse me. For one, they are too small. A Metaspace node is 64M sized. It can contain multiple committed and reserved sections, so typically spreads over multiple lines, but usually not many. Here (G1 file), I see many that are 64K in size, spanning in total just about 5MB. You can counter-check the META blocks with `jcmd .. VM.metaspace vslist` - it prints the virtual space node list at the start.
- Another thing that is strange is that the MEAT lines are not coalesced, though the properties displayed seem to be the same. But that can be the result of hidden properties being different.

Also, could you rename the OS-specific names to `[lowercase-something]`? The `[UPPERCASE]` names are easily confused with the uppercase NMT tags.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/20953#issuecomment-2454804578


More information about the serviceability-dev mailing list