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

[David Holmes]

Thanks Dean. Sorry I'd already pushed it.

David

On 11/09/2018 9:25 AM, dean.long at oracle.com wrote:
> +1 for this change
> +1 for learning new things :-)
> 
> dl
> 
> On 9/10/18 4:16 PM, serguei.spitsyn at oracle.com wrote:
>> I also tried to learn from your email exchange with Dean L.
>>
>> Thanks,
>> Serguei
>>
>>
>> On 9/10/18 15:59, David Holmes wrote:
>>> Thanks for the reviews Serguei and JC.
>>>
>>> On 11/09/2018 8:10 AM, JC Beyler wrote:
>>>> 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).
>>>
>>> :) I've learnt a few things with these changes too.
>>>
>>> Cheers,
>>> David
>>>
>>>> Thanks!
>>>> Jc
>>>>
>>>> On Mon, Sep 10, 2018 at 2:59 PM serguei.spitsyn at oracle.com 
>>>> <mailto:serguei.spitsyn at oracle.com> <serguei.spitsyn at oracle.com 
>>>> <mailto: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/
>>>> <http://cr.openjdk.java.net/%7Edholmes/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
>>
>