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