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

[JC Beyler]

Ok makes sense then: it is not specified what happens to locals that are
out of scope and therefore depending on the compiler/modes/tiers, you could
get a different return in those cases.

Webrev looks good to me now :)
Jc

On Mon, Nov 12, 2018 at 8:06 PM serguei.spitsyn at oracle.com <
serguei.spitsyn at oracle.com> wrote:

> On 11/12/18 20:05, serguei.spitsyn at oracle.com wrote:
>
> Hi Jc,
>
>
> Thank you a lot for reviewing!
>
> On 11/12/18 09:35, JC Beyler wrote:
>
> 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").
>
>
> I also normally do not like commented out code.
> In this particular case, I considered commented out lines as part of
> comment.
> They explain what is removed better than any words. :)
>
> Okay, I've removed these lines with the comment.
>
>
> Forgot to tell that I've updated the same webrev:
>
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2018/8213525-unstable-test.1/
>
>
> Thanks,
> Serguei
>
> 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?
>
>
> No.
> There is no information from the JIT compiler to return errors when the
> LVT is absent.
> Moreover, different compilers, modes or tiers differently represent local
> values that are out of scope.
>
> Thanks,
> Serguei
>
>
> 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
>
>
>
>

-- 

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