RFR(S) 8241071 Generation of classes.jsa is not deterministic
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Mon Apr 27 08:35:15 UTC 2020
Hi Ioi,
On 2020-04-27 07:22, Ioi Lam wrote:
> https://bugs.openjdk.java.net/browse/JDK-8241071
> http://cr.openjdk.java.net/~iklam/jdk15/8241071-deterministic-cds-archive.v02/
>
I can't really comment on the code changes, but I'd like to thank you
for the effort of getting a deterministic classes.jsa. This is a big
step towards the goal of getting deterministic, reproducible builds of
the JDK.
/Magnus
>
> 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).
> 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 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.
>
> Thanks
> - Ioi
More information about the hotspot-runtime-dev
mailing list