RFR(S) 8241071 Generation of classes.jsa is not deterministic

[Jiangli Zhou]

Hi Ioi,

I only took a quick look and this looked okay generally. I will read
it more closely. I like David's alternative suggestion of using a VM
defined system property. What's your thought on that?

Thank you for the effort on improving the .jsa deterministic. This
will help improve CDS usability longer term and also improve build
process in some cases.

Best,
Jiangli

On Sun, Apr 26, 2020 at 10:33 PM Ioi Lam <ioi.lam at oracle.com> 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).
>      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