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

David Holmes david.holmes at oracle.com
Mon Apr 27 06:20:26 UTC 2020


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


More information about the hotspot-runtime-dev mailing list