RFR(XS) 8209823 Replace Verifier::load_class with a simple lookup of super classes
coleen.phillimore at oracle.com
coleen.phillimore at oracle.com
Tue Aug 28 12:05:11 UTC 2018
On 8/27/18 8:33 PM, dean.long at oracle.com wrote:
> On 8/27/18 4:02 PM, Ioi Lam wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8209823
>> 8209823-simplify-verifier-load-class.v01/
>>
>> Please review this small clean up:
>>
>> Verifier::load_class(name) is called only when name is known to
>> be the name of a super class of the current class. At this point,
>> the super class should have already been loaded. Also, the loader
>> of the current class should have already recorded the super
>> class as a dependency.
>>
>
> I'm not an expert, so I have to ask: is there a dependency from the
> current class to its "super supers" (its grandparent and higher)? I
> believe the "super super" was resolved with "super" and the current
> class, but if there is no dependency from the current class to
> super->super or super->super->super, then wouldn't that allow a
> misbehaving classloader to return a different class for the
> load_class() call?
The dependencies are transitive, so each class has a dependency to their
supers, who have a dependency on their supers. So none of the
grandparents can be unloaded with these dependencies.
Coleen
>
> dl
>
>> Therefore, load_class does a lot of work (such as resolving the
>> super class by name) that's not necessary. Also, load_class is
>> declared to potentially throw exceptions. This makes code analysis
>> more complicated.
>>
>> The fix is to remove load_class() altogether and change
>> ClassVerifier::name_in_supers to also return the super's.
>> InstanceKlass*
>>
>> Thanks
>> - Ioi
>
More information about the hotspot-runtime-dev
mailing list