This is similar to [JDK-8245168](https://bugs.openjdk.org/browse/JDK-8245168), but the blanket change to allow all modules be compiled with default options is a net loss. Instead, we can hand-pick the major offenders (large modules) where running jmod with normal tool options improves performance.
I instrumented the jmod to tell me the times it needs to create individual modules, and hand-picked three top modules that take multiple seconds to run. Motivational `make clean-images images` times: # x86_64 Server, release # Baseline real 0m12.040s user 1m4.872s sys 0m10.805s # Patched real 0m10.785s ; <--- 1.2s faster user 1m7.031s sys 0m10.985s # x86_64 Server, fastdebug # Baseline real 0m19.263s user 2m42.317s sys 0m18.537s # Patched real 0m17.911s ; <--- 1.1s faster user 2m52.810s sys 0m19.092s # x86_64 Server, slowdebug # Baseline real 0m44.799s user 10m7.106s sys 0m17.578s # Patched real 0m46.975s ; <--- 2.5 sec slower user 11m1.155s sys 0m17.060s I think we can accept the `slowdebug` regression in favor of improvements on `release` and `fastdebug` that most people seem to be building every day. ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/10062/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10062&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293020 Stats: 8 lines in 2 files changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10062.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10062/head:pull/10062 PR: https://git.openjdk.org/jdk/pull/10062
