RFR(S) 8240244 Avoid calling resolve_super_or_fail in SystemDictionary::load_shared_class

Claes Redestad claes.redestad at oracle.com
Tue Mar 3 11:15:48 UTC 2020


Hi Ioi,

overall looks good, thanks!

systemDictionary.cpp

I'm not sure what you meant to write here:

+  // + Don't take the lock if loader data is NULL without taking lock.

Left-over "!= 0":

+  if (!super_type->is_shared_unregistered_class() != 0 && 
super_type->class_loader_data() != NULL) {

--

It seems to me that it might be possible to take the
SystemDictionary_lock just once in check_shared_class_super_types
method, spanning super and all interfaces. That might need some
restructuring since we can't hold that lock when going into
the class-loading slow path, but I think the slow path could profitably
be moved to the outer method outside such a locked section.

Thanks!

/Claes

On 2020-03-03 07:34, Ioi Lam wrote:
> https://bugs.openjdk.java.net/browse/JDK-8240244
> http://cr.openjdk.java.net/~iklam/jdk15/8240244-reduce-resolve-super.v01/
> 
> When loading shared classes from the CDS archive, we need to test if the
> actually loaded super types are the same as those used during CDS dumping.
> That was done with a pretty expensive call to resolve_super_or_fail.
> 
> In most cases, the super type has already been loaded (about 350 out of 400
> cases when running HelloWorld), so we can quickly determine that by
> doing a look up in the super type's dictionary.
> 
> This saves about 250,000 out of about 112M instructions (about 0.22%) when
> running HelloWorld with the default archive on Linux/x64.
> 
> I also renamed a few functions in instanceKlass.hpp to _xxx_shared_xxx 
> since
> they are used only for CDS.
> 
> Thanks
> - Ioi
> 
> 


More information about the hotspot-runtime-dev mailing list