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