RFR: 8263421: Module image file is opened twice during VM startup [v2]

David Holmes dholmes at openjdk.java.net
Thu Apr 22 02:28:21 UTC 2021


On Wed, 21 Apr 2021 18:51:02 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this fix for JDK-8263421.  The fix stores the JImageFile* in a static that gets initialized when lookup_vm_options() opens the module image file.  The static JimageFIle* is then used by setup_bootstrap_search_path_impl() when creating the ClassPathImageEntry for the module image file, avoiding having to re-open the module image file.
>> 
>> This fix moved the creation of the ClassPathImageEntry for the module image file from create_class_path_entry() to setup_bootstrap_search_path_impl() because create_class_path_entry() may try to do this multiple times, but the ClassPathImageEntry for the module image file is only actually created once.
>> 
>> The fix also removes some unused code related to module image file processing.
>> 
>> The changes were tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-
>> 5 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add jimage_non_null(), modify destructor

Hi Harold,

Generally this looks okay. A couple of minor nits.

Thanks,
David

src/hotspot/share/classfile/classLoader.cpp line 112:

> 110: 
> 111: // JimageFile pointer, or null if exploded JDK build.
> 112: static JImageFile*                     JImage_File            = NULL;

Naming style looks odd here - JImage_file ? _jimage_file ?

src/hotspot/share/classfile/classLoader.cpp line 360:

> 358: void ClassPathImageEntry::set_jimage(JImageFile* jimage) {
> 359:   JImage_File = jimage;
> 360: }

This setter seems overkill, especially when it is only used to clear the field, and there is no setter used when giving the field a real value.

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

Marked as reviewed by dholmes (Reviewer).

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


More information about the hotspot-runtime-dev mailing list