RFR (XS): 8213525: new unit test GetLocalVariable/LocalVars is not stable

[JC Beyler]

Hi Serguei,

The fix looks good (though I never like commented out code, why do we not
just remove the lines and add a simple comment: "Due to JDK-8213525, we do
not test X,Y, and Z because of stability isssues").

But the underlying question I have that is not really explained is : "why
is it failing?"; is the spec not specific in these cases? is it a bug in
the compiler/runtime that is not yet fixed to conform to the spec? I ask
because I would imagine that it might be something we would like to fix, no?

Thanks,
Jc



On Mon, Nov 12, 2018 at 2:25 AM serguei.spitsyn at oracle.com <
serguei.spitsyn at oracle.com> wrote:

> Please, review a fix for:
>   https://bugs.openjdk.java.net/browse/JDK-8213525
>
> Webrev:
>
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2018/8213525-unstable-test.1/
>
>
> Summary:
>   A couple of the checks in new unit test developed for JDK-8080406
> <https://bugs.openjdk.java.net/browse/JDK-8080406> is not stable.
>   It is expected that the type of the local intLoc returned by the StackValueCollection
> has
>   to be T_CONFLICT as it is out of scope at the point where the
> testLocals() is called:
>
>      int staticMeth(byte byteArg, Object objArg, double dblArg, int intArg) {         testLocals(Thread.currentThread());         {             int intLoc = 9999;             intArg = intLoc;         }         return intArg;     }
>
>   But sometimes the type T_INT is returned instead of T_CONFLICT.
>   The fix is to disable the checks that can fail because of it.
>
>
> Thanks,
> Serguei
>
>

-- 

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