On Tue, 8 Sep 2020 15:59:33 GMT, Ioi Lam <ik...@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-...@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-...@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
