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.

> 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