RFR: 8314986: Module readability resolution is slow with large numbers of automatic modules

[Technici4n]

On Tue, 26 Sep 2023 14:19:55 GMT, Technici4n <duke at 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