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.


> 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