RFR: 8283474: Include detailed heap object info in CDS map file

[Thomas Stuefe]

On Mon, 21 Mar 2022 22:10:26 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The cds.map file produced by `java -Xshare:dump -Xlog:cds+map=trace:file=cds.map:none:filesize=0` is useful in diagnosing problems with deterministic CDS archive files, such as [JDK-8253495](https://bugs.openjdk.java.net/browse/JDK-8253495).
> 
> Currently, cds.map has information of each individual **metaspace object**. For example:
> 
> 
> [ro region 0x00000008004ca000 - 0x0000000800c452e8 7844584 bytes]
> 0x00000008004ca000:
> 0x00000008004ca000: @@ Symbol 8 [Z
> 0x00000008004ca000: 5a5b0002e99effff
> 0x00000008004ca008: @@ Symbol 8 [C
> 0x00000008004ca008: 435b000299a9ffff
> ...
> 0x0000000800bcd838: @@ TypeArrayU1 16
> 0x0000000800bcd838: 3e00010000000006 0000000000000000
> 0x0000000800bcd848: @@ ConstMethod 104 java.lang.String java.lang.Object.toString()
> 0x0000000800bcd848: 0000000000000018 0000000800651da8 0000000000000000 000c00050000000d
> 0x0000000800bcd868: 0006001200250024 0006000100010002 ec0000b7590100bb 03b60002b60001b6
> 0x0000000800bcd888: b6ec0003b600e600 0003b60005b80004 05c000ffb00006b6 003b002400000000
> 0x0000000800bcd8a8: 000100000000003c
> 
> 
> This RFE adds the following info into the cds.map file to describe the **heap objects**:
> 
> 
> [closed heap region 0x00000007bf800000 - 0x00000007bf87e000 516096 bytes]
> 0x00000007bf800000: @@ Object [B
> 0x00000007bf800000: 00000003f021ab01 0000000000002090
> 0x00000007bf800010: @@ Object java.lang.String
> 0x00000007bf800010: 0000000d37cfa501 00000000000091d8 f7f0000000010100
> ...

Hi Ioi,

nice, I had a fun time looking at the archive dump.

I wondered whether it would be more convenient to print out 32-bit words instead of 64-bit words, to better separate the narrow class word from the object start. But that would tear the mark word, so one would have to do mental gymnastics either way.

I tried this on 32-bit too, but this is not supported on 32bit?

Stupid question, the fact that all objects are having "01" as least byte means all are unlocked and we never had a GC running before dump time, right?

Cheers, Thomas

src/hotspot/share/cds/archiveBuilder.cpp line 1067:

> 1065:       }
> 1066:     }
> 1067: #endif

Not part of your patch, but as a casual reader I would like it if you reserved "write" and "dump" for actual archive writing, and used "log" consistently for logging. There are functions named "write_xxx" doing either, or both. Also, comment talks about "Dump all the data.." (at write_data) when all it does is logging.

I know we are within the context of "CDSLogger" here, so it's kind of obvious. But it would help bystanders to understand the code.

src/hotspot/share/cds/heapShared.hpp line 261:

> 259:       mtClassShared,
> 260:       HeapShared::oop_hash> OriginalObjectTable;
> 261:   static OriginalObjectTable* _original_object_table;

Did a small test, and a hello world creates a map with 33k objects. So this will have a load factor > 2, is that okay? 

Maybe we should create and fill this map only when logging. Its only used for logging, right? Why pay for this map always. Archive creation at build is already kind of slow.

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

PR: https://git.openjdk.java.net/jdk/pull/7895