RFR(M) 8208999 Some use of Klass* should be replaced by InstanceKlass*

John Rose john.r.rose at oracle.com
Tue Aug 28 16:48:02 UTC 2018


On Aug 6, 2018, at 2:26 PM, Ioi Lam <ioi.lam at oracle.com> wrote:
> 
> 3. SystemDictionary::resolve_super_or_fail() currently accepts the format
>    of "Ljava/lang/Object;" for the "super_name" parameter. I am keeping the
>    same behavior in my patch. However, I wonder if this actually correct
>    per JVMLS. I filed JDK-8209030.

I have wanted that cleaned up for a very long time.  I posted a comment
on JDK-8209030.  This is a good time to fix it, since the surrounding code
is being disturbed.

This is overall a good cleanup.  I have to say, though, that I'm surprised
that ArrayKlass didn't give you more trouble.  As noted in your comments,
the super of T[] is U[] when U is the super of T, so java_super has to go
all the up to java/lang/Object if it is to be an InstanceKlass.  I guess the
name "java_super" is the source of the surprise:  It should be named
"super_instance_class" or some such.  The "Java super" of T[] is U[]
or Object when T is Object, so "java_super" is a misleading misnomer.

It seems to me that we would have been happier in the long run if we
had chosen to make ArrayKlass <: InstanceKlass.  That would allow
java_super to be a real Java super query, and would provide room
for methods (now toString/clone, more later) on array klasses without
the current terrible v-table hacks.  But maybe that's just the grass being
greener on the other side of the fence?

— John


More information about the hotspot-runtime-dev mailing list