RFR(s): 8231630: Optimize boot loader with no bootclasspath append entry

Jiangli Zhou jianglizhou at google.com
Mon Oct 7 16:31:55 UTC 2019

Thanks, Lois! Please see comments below.

On Mon, Oct 7, 2019 at 9:07 AM Lois Foltan <lois.foltan at oracle.com> wrote:
> On 10/5/2019 4:28 PM, Jiangli Zhou wrote:
> > Please review the following small optimization for boot loader.
> >
> > webrev: http://cr.openjdk.java.net/~jiangli/8231630/webrev.00/
> > RFE: https://bugs.openjdk.java.net/browse/JDK-8231630
> >
> > During classloading, the boot loader in the delegation path calls
> > SystemDictionary::load_instance_class to load a requested class. After
> > the module system is initialized, the VM checks if the requested
> > class' package is in a module defined to the boot loader. If the class
> > is either in the unnamed package or unnamed module, or in a module not
> > defined to the boot loader, the VM only searches the bootloader's
> > append entry (or entries). As a simple optimization, if there is no
> > boot append entry, we can immediately return NULL in that case without
> > any additional work. This particular call path is heavily exercised in
> > some microbenchmarks, such as Dacapo 'pmd'. The improvement is mostly
> > within noise level and may be un-noticeable for real world
> > applications, but does show a ~3% difference with 'pmd' in
> > Before/After comparison. As 'pmd' results can be noisy, the comparison
> > is done with a large number of benchmark runs.
> >
> > Testing with submit-repo tests.
> >
> > Best regards,
> > Jiangli
> Looks good Jiangli.
> One clarification question, I assume then the class could never be in
> the CDS archive?  By returning, line #1453-1456 will be skipped.

Yes, it is guaranteed by the archive and shared class path validation.
Since the contents within the modules image are the same for both dump
time and runtime, if the VM determines that a class is not in the
modules (only searches the bootclasspath append if exists), it must
not in the CDS archive either.

Best regards,


> Thanks,
> Lois

More information about the hotspot-runtime-dev mailing list