RFR(s) 8221351 Crash in KlassFactory::check_shared_class_file_load_hook

David Holmes david.holmes at oracle.com
Wed Mar 27 02:08:51 UTC 2019

Hi Ioi,

This all seems fine to me. Will this also now account for modules loaded 
with the App loader or even a custom loader?

Is there anywhere else we might assume we're dealing with the boot loader?


On 27/03/2019 4:26 am, Ioi Lam wrote:
> https://bugs.openjdk.java.net/browse/JDK-8221351
> http://cr.openjdk.java.net/~iklam/jdk13/8221351-cds-jfr-jvmti-crash.v01/
> The crash happens when we try to read the classfile data for the shared
> class java.sql.SQLException. This ultimately goes to
> ClassPathImageEntry::open_stream, which calls JImageFindResource.
> However, JImageFindResource needs to know the module_name ("java.sql")
> for this class, but the module_name look up is done only using the boot
> loader, which doesn't know about the java.sql module, which is loaded by 
> the
> built-in platform loader.
> The fix is to pass the defining class loader down to
> ClassPathImageEntry::open_stream_for_loader, so that the module_name 
> look-up
> can be done using the correct loader.
> While fixing this, I also removed an obsolete "#if INCLUDE_CDS" in
> classLoader.cpp. This was relic from the days when we still used the boot
> loader to load platform/app classes. This code is no longer needed after
> JDK-8186842 (Use Java class loaders for creating the CDS archive).
> Tested with tier-{1,2,3}
> Thanks
> - Ioi

More information about the hotspot-runtime-dev mailing list