RFR(M) 8208999 Some use of Klass* should be replaced by InstanceKlass*
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?
More information about the hotspot-runtime-dev