RFR: (S) 8210512: [Testbug] vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails with unexpected size of ClassLoaderReference.referringObjects

[JC Beyler]

Hi David,

Looks good to me (I'm not a reviewer but wanted to piggy-back and say I
actually learnt quite a bit with the conversation on the original webrev).

Thanks!
Jc

On Mon, Sep 10, 2018 at 2:59 PM serguei.spitsyn at oracle.com <
serguei.spitsyn at oracle.com> wrote:

> Hi David,
>
> It looks good to me.
> Thank you for taking care about it!
>
> Thanks,
> Serguei
>
>
> On 9/10/18 14:31, 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_class in JVMS 4.1)
> > and that is what we were encountering here.
> >
> > For the empty class used in the test this reference remains
> > unresolved, but in general it could be resolved and would otherwise be
> > found. So the fix for the test is to now expect to always find this
> > self-reference.
> >
> > Thanks,
> > David
>
>

-- 

Thanks,
Jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180910/a645aa29/attachment-0001.html>