+1 for this change
+1 for learning new things :-)
dl
On 9/10/18 4:16 PM, serguei.spit...@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.spit...@oracle.com
<mailto:serguei.spit...@oracle.com> <serguei.spit...@oracle.com
<mailto:serguei.spit...@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
