[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Re: RFR: 8283474: Include detailed heap object info in CDS map file
From:       Thomas Stuefe <stuefe () openjdk ! java ! net>
Date:       2022-03-30 14:51:36
Message-ID: BlLVFjp6uSsZeaa2yhH_pN1VkTLv9KVhjY8XRdmdMvE=.899079a0-c9f8-4441-a911-4f4d59611091 () github ! com
[Download RAW message or body]

On Mon, 21 Mar 2022 22:10:26 GMT, Ioi Lam <iklam@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


[prev in list] [next in list] [prev in thread] [next in thread]