RFR: 8316969: Improve CDS module graph support for --module option [v3]

[Calvin Cheung]

On Sat, 28 Oct 2023 06:37:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The `ArchivedModuleGraph.java` wasn't changed. So if `-m` is not specified, the `archivedModuleGraph` is non-null; if `-m` is specified, the `archivedModuleGraph` is null.
>> So running `java -version`, the archivedModuleGraph is non-null, but the module m won't be loaded from the archive. I'm seeing the following log output:
>> 
>> `[0.220s][debug][module     ] define_module(): creation of module: m, version: null, location: jrt:/m, loader data: 0x00007f201819dd60 for instance a 'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x000000011f010500}, package #: 1`
>
>> The `ArchivedModuleGraph.java` wasn't changed. So if `-m` is not specified, the `archivedModuleGraph` is non-null; if `-m` is specified, the `archivedModuleGraph` is null. So running `java -version`, the archivedModuleGraph is non-null, but the module m won't be loaded from the archive.
> 
> Right, but ArchivedModuleGraph provides the initial value for hasIncubatorModules, hasSplitPackages, ... This is why `java -version` confusingly prints a warning that an incubator module has been resolved. We've had archiving of the module graph (configuration) for a long time but it's only been for the case where the initial module is the unnamed module. I think archiving of the boot layer for the case where the initial module is a named module means we have to re-visit ArchivedModuleGraph. I think ArchivedModuleGraph.get has to return null when the archive doesn't match the mainModule. Part of it wonder if we should remove ArchivedModuleGraph, support archiving of the boot layer only.

I've added the following field in `ArchivedModuleGraph` so that the `get(String mainModuleName)` will check the `mainModule` before returning `archivedModuleGraph`.
`private static String mainModule;`
The `mainModule` field is also added in `heapShared.cpp` so that it is stored in the archive.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1377099846