Hi Ioi,
On 27/04/2020 3:22 pm, Ioi Lam wrote:
https://bugs.openjdk.java.net/browse/JDK-8241071
http://cr.openjdk.java.net/~iklam/jdk15/8241071-deterministic-cds-archive.v02/
The goal is to for "java -Xshare:dump" to produce deterministic contents in
the CDS archive that depend only on the contents of $JAVA_HOME/lib/modules.
Problems:
[1] Symbols in the CDS archive may have non-deterministic order because
Arena allocation is non-deterministic.
[2] The contents of the CDS shared heap region may be randomized due to
ImmutableCollections.SALT32L.
Fixes:
[1] With -Xshare:dump, allocate Symbols from the class space (64-bit only).
I'm not seeing what restricts this to 64-bit only ??
Will changing the allocation of symbols cause any problems with the
amount of "class space" we need?
See changes in symbol.cpp for details.
[2] When running the VM with -Xshare:dump, ImmutableCollections.SALT32L is
initialized with a deterministic seed. NOTE: this affects ONLY when
the
VM is running with the special flag -Xshare:dump to dump the CDS
archive.
It does NOT affect normal execution of Java programs.
I can't say I like adding in the VM call for this. Another alternative
would be a VM defined system property. But I'll let core-libs folk make
the call here.
---
I also cleaned up the -Xlog:cds output and print out the CRC of each
CDS region, to help diagnose why two CDS archives may have different
contents.
Generally seems okay. A couple of minor nits:
src/hotspot/share/oops/symbol.cpp
typo: adresses -> addresses
test/hotspot/jtreg/runtime/cds/DeterministicDump.java
Should the test use @driver mode?
39 // use of SharedArchiveFile argument.
s/argument/arguments/
40 // methods to form command line to create/use shared archive.
s/line/lines/
s/shared/the shared/
71 if (n0 == 0) {
Shouldn't this check come before the loop at line 63?
Thanks,
David
-----
Thanks
- Ioi
