Hi David. If a class references its own fields or methods, and that
code is executed by the interpreter, then we should expect that constant
pool entry to be resolved, shouldn't we? Likewise the compiler will
treat it as resolved. If we treat is as unresolved, we run into the
case where we executed compiled code for a method that would have
resolved the constant pool entry, but JVMTI says we didn't.
Isn't the test in error for assuming no eager resolution?
By the way, it looks like we always eagerly resolve this_class for
unsafe-anonymous classes.
dl
On 9/9/18 10:51 PM, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8210512
Webrev: http://cr.openjdk.java.net/~dholmes/8210512/webrev/
After the fix for JDK-8209361 where we modified JVM-TI to treat an
unresolved CP klass entry to a loaded klass as a resolved CP entry,
the listed test starting failing due to finding an extra reference to
the test class. As outlined in the bug report this extra reference:
17: instance of java.lang.Class(reflected
class=nsk.share.jdi.TestClass1, id=792)
actually comes from the class itself. Every classfile has a
self-referential entry in the constant pool (this_klass in JVMS 4.1)
and that is what we were encountering here.
I would argue that such an unresolved reference from a class to itself
should never be treated as a "real" reference from a JVM TI
perspective, and so we ship skip it - which is what the fix does:
- if (klass == NULL) {
+ if (klass == NULL || klass == ik) {
continue;
Testing: the test concerned
joatc testing of test that failed in 8209361 (TBD)
mach5 tiers 1-3 (TBD)
jvmti (TBD)
As noted testing is still TBD other then actual test but there are
technical delays with that so I'll get the RFR out anyway.
Thanks,
David
