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