On Tue, 26 Sep 2023 14:19:55 GMT, Technici4n <d...@openjdk.org> wrote:
> Fixes the issue (hopefully) by resolving automatic modules and automatic > module dependencies after propagation of non-automatic transitive > dependencies. The module tests run. > > I also added a few asserts to validate that the automatic modules don't read > themselves (previously this was the case with > 1 automatic module). Should > these asserts be added in more places or is this enough? > > Alan also mentioned a conflict with the spec, I'm not sure which spec is > being referred to. The documentation of `ResolvedModule#reads` states `A > possibly-empty unmodifiable set`, implying that the set can be empty. > > Finally, `Configuration#reads` states `// The sets stored in the graph are > already immutable sets` but that does not seem to be true. Should something > be done about this to limit allocation? > > Please let me know! > Cheers The attached patch helps a lot when there's only automatic modules, but not so much with many non-automatic modules. See for example this updated "test": https://gist.github.com/Technici4n/5ac0744bb85604ed9f81c610151cc884 and the following output: (numbers not scientific) [standard jdk 20] Time for 100 modules = 0.0s Time for 200 modules = 0.1s Time for 300 modules = 0.3s Time for 400 modules = 0.4s Time for 500 modules = 1.0s Time for 600 modules = 1.7s Time for 700 modules = 2.5s Time for 800 modules = 4.6s Time for 900 modules = 5.9s Time for 1000 modules = 6.6s [with Alan's patch] Time for 100 modules = 0.0s Time for 200 modules = 0.0s Time for 300 modules = 0.1s Time for 400 modules = 0.2s Time for 500 modules = 0.3s Time for 600 modules = 0.5s Time for 700 modules = 0.9s Time for 800 modules = 1.5s Time for 900 modules = 1.9s Time for 1000 modules = 1.9s ------------- PR Comment: https://git.openjdk.org/jdk/pull/15926#issuecomment-1735822630
