RFR: 8293017: Improve hash calculation parallelism in jmod/jlink

Aleksey Shipilev shade at openjdk.org
Mon Aug 29 10:54:08 UTC 2022


On Mon, 29 Aug 2022 09:18:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This issue will require discussion as it potentially impacts usage at run-time when the resolver runs at startup or when creating module layers. 

Startup with/without CDS:


$ perf stat -r 100 build/linux-x86_64-server-release/images/jdk/bin/java Hello

# Baseline
 With CDS: 0.0323543 +- 0.0000789 seconds time elapsed  ( +-  0.24% )
 Without CDS: 0.071471 +- 0.000500 seconds time elapsed  ( +-  0.70% )

# Patched
 With CDS: 0.0328651 +- 0.0000780 seconds time elapsed  ( +-  0.24% )
 Without CDS:  0.072745 +- 0.000472 seconds time elapsed  ( +-  0.65% )


So there seem to be some minor impact, but nothing drastic. I would be very surprised if we actually verified the module hashes at startup! That would take minutes to startup on Zero, as observed by its build-time checking. And we don't see that, apparently.

> I also wonder if it has an impact on JDK builds where many jobs are running jmod at the same time. It may be that this has to be configured by a system property so that it can be enabled only in the JDK build.

The normal build already runs a lot of `jmod`-s at once. But that would not help when you have the fat `jmod java.base` at the end of the build, where no external parallelism exists. At that point, internal `Resolver` parallelism helps a lot.

> Also just to say that Claes removed all the lambda expressions from this code in JDK 9 to help with startup as that will have to checking too. Also if we are changing this code then we should try to keep the style/conventions/line-lengths consistent where possible.

I reverted some brace changes.

-------------

PR: https://git.openjdk.org/jdk/pull/10060


More information about the core-libs-dev mailing list