On Mon, 29 Aug 2022 09:18:16 GMT, Alan Bateman <al...@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
