RFR 8251557 Avoid dumping unused symbols/strings into the CDS archive
calvin.cheung at oracle.com
calvin.cheung at oracle.com
Wed Aug 26 16:40:34 UTC 2020
Hi Ioi,
The proposed change does make the code easier to read than before.
I've comments on 2 files:
heapShared.hpp:
42 class DumpedInternedStrings;
Instead of forward declaration, is it possible to move the class
definition there since it is defined at the end of the file?
archiveBuilder.hpp:
37 class DumpRegion;
The above forward declaration was removed but I think it's required for
the following:
132 DumpRegion* _rw_region;
133 DumpRegion* _ro_region;
Also, the following constructor needs to be moved to archiveBuilder.cpp
or I got compile error about invalid use of incomplete type 'class
DumpRegion'.
158 OtherROAllocMark() {
159 _oldtop = _singleton->_ro_region->top();
160 }
thanks,
Calvin
On 8/19/20 2:39 PM, Ioi Lam wrote:
> https://bugs.openjdk.java.net/browse/JDK-8251557
> http://cr.openjdk.java.net/~iklam/jdk16/8251557-cds-dont-dump-unused-symbols.v01/
>
>
> Part of CDS code clean up:
>
> Currently all entries in the SymbolTable/StringTable are dumped into
> the CDS archive. The problems are
>
> (1) We end up writing many unused items, such as the mangled names
> of hidden classes.
> (2) We have to scan the symbol table inside a safepoint, which had
> caused bugs before (JDK-8245264).
>
> Since JDK-8250990, we already maintain all used Symbols in a growable
> array. We can dump the shared symbol table using this array, and
> avoid walking the SymbolTable.
>
> For StringTable, we scan all archived classes, and dump only the
> interned strings used by those classes (plus extra strings
> specified by SharedArchiveConfigFile) into the CDS interned string
> table.
>
> This reduces complexity in the CDS code, and reduce the size of
> the CDS archives.
>
> Testing - tiers 1-4
>
> Archive file size for "java -Xshare:dump"
>
> old: 39,368 symbols 7,028 strings 11,784,200 bytes
> new: 37,387 symbols 7,020 strings 11,683,320 bytes (~0.9% reduction)
>
> Thanks
> - Ioi
>
>
More information about the hotspot-runtime-dev
mailing list