RFR: 8176472: Lazily create ModuleEntryTable

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Fri Apr 14 19:28:19 UTC 2017

Hi Rachel,  This looks great.  I have one comment:


+static ModuleEntry* get_unnamed_module(Handle h_loader, TRAPS) {
+ // This code can be called during start-up, before the classLoader's 
classLoader data got
+ // created. So, call register_loader() to make sure the classLoader 
data gets created.
+ ClassLoaderData *loader_cld = 
SystemDictionary::register_loader(h_loader, CHECK_NULL);
+ return loader_cld->unnamed_module();

Calling this for the the boot loader doesn't make sense, because the 
boot loader is created at startup (and the h_loader should be NULL 
passed in).  It makes sense for the other module entries 
(get_module_entry) calls I guess.

In this case, you know that the boot_loader is 
ClassLoaderData::the_null_class_loader_data(), so you can use that directly.


On 4/14/17 1:48 PM, Rachel Protacio wrote:
> Thanks, Harold (and George)!
> has_reads_list() sounds reasonable to me. Here's that webrev: 
> http://cr.openjdk.java.net/~rprotacio/8176472.01/
> Thanks,
> Rachel
> On 4/14/2017 11:03 AM, harold seigel wrote:
>> Hi Rachel,
>> The changes look good!  They will definitely save memory.
>> Would it be useful to rename ModuleEntry::has_reads() to something 
>> like ModuleEntry::has_reads_list() ?
>> Thanks, Harold
>> On 4/14/2017 10:34 AM, Rachel Protacio wrote:
>>> Hello!
>>> Please review this enhancement which moves the unnamed module out of 
>>> the ModuleEntryTable and into the ClassLoaderData so that the MET 
>>> can be lazily created only when other modules are present. The 
>>> PackageTable size has also been updated to be more realistic. These 
>>> two changes save the VM from losing memory space unnecessarily in 
>>> the module data structures.
>>> Tested with JPRT and RBT tiers 2-5.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8176472
>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8176472.00/
>>> Thank you,
>>> Rachel

More information about the hotspot-runtime-dev mailing list