RFR: 8244778: Archive full module graph in CDS

[Ioi Lam]

On Tue, 8 Sep 2020 15:59:33 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is the same patch as
> [8244778-archive-full-module-graph.v03](http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v03/)
> published in
> [hotspot-runtime-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041496.html).
> The rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail.

In response to Lois Foltain's comments on
[hotspot-runtime-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041616.html):

> Minor nit in moduleEntry.cpp & packageEntry.cpp when dealing with the ModuleEntry's reads list and a PackageEntry's
> exports list.  The names of the methods to write and read those arrays is somewhat confusing.
>
> ModuleEntry::write_archived_entry_array
> ModuleEntry::read_archived_entry_array
>
> At first I thought you were reading/writing an array of archived entries, not the array within an archived entry
> itself.  I was trying to think of a better name.  Please consider adding a comment at line #400 & line #417 ahead of
> those methods in moduleEntry.cpp to indicate that they are used for both reading/writing a ModuleEntry's reads list and
> a PackageEntry's exports list.

I renamed the functions to `ModuleEntry's::write_growable_array` and `ModuleEntry::restore_growable_array`, and added
comments as you suggested. See commit
[4f90e77](https://github.com/openjdk/jdk/pull/80/commits/4f90e77207de5fc7cf09a12fb89b75087be57225)

// This function is used to archive ModuleEntry::_reads and PackageEntry::_qualified_exports.
// GrowableArray cannot be directly archived, as it needs to be expandable at runtime.
// Write it out as an Array, and convert it back to GrowableArray at runtime.
Array<ModuleEntry*>* ModuleEntry::write_growable_array(GrowableArray<ModuleEntry*>* array) {

> A question about this because a user's program can define modules post module initialization via
> ModuleDescriptor.newModule().  See for example, tests within open/test/hotspot/jtreg/runtime/module/AccessCheck.  So
> all of these tests would trigger check_cds_restrictions() if -Xshare:dump was turned on.  Is that a concern?

Arbitrary user code cannot be executed during -Xshare:dump. The only way to do it is to use a JVMTI agent, which
requires specifying `-XX:+AllowArchivingWithJavaAgent`. You can see an example in the
[GCDuringDump.java](https://github.com/openjdk/jdk/blob/704f784c88ee282837c980948167e741e7227f27/test/hotspot/jtreg/runtime/cds/appcds/javaldr/GCDuringDump.java#L65)
test. If the agent tries to define an extra module, it will get an `UnsupportedOperationException` thrown by
`check_cds_restrictions()`.

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

PR: https://git.openjdk.java.net/jdk/pull/80