Startup time regressed in JDK 9 (compared to JDK 8). Much of the regression is due to the initialization of the module system as it involves executing additional java code as part of creating the VM.

This issue tracks reducing the code as follows:

- Avoid reconstituting the module descriptors for modules that will not be resolved. When the initial module is the class path then this avoids reconstituting the module descriptors for the EE modules and also several tool modules.

- Generate the readability graph at link time for initial modules that are known at link time.

- Elide checks for incubating modules when there are no incubating modules in the readability graph.

- Creating the built-in class loaders requires scanning the elements in the class path. This can be improved by translating the file paths to URLs using the legacy implementation which avoids loading the new file system API early in the startup. This change will also re-align resource lookup with -Xbootclasspath/a when there are empty elements in the class path.

- Usages of method references in the 2-arg Class.forName and BuiltinClassLoader can be replaced to avoid early initialization of the lambda forms implementation for the case that the initial module is in the run-time image.

- jl.Module is loaded by the VM before initPhase1, its static initializer can be removed and the reflective data moved to a holder class.

- URLs are created as part of initializing the class path and built-in class loaders. The URL creation should not need to load the Locale and related classes for the common cases.