Thanks a lot, Chris!
Serguei
On 11/13/18 10:55 AM, Chris Plummer wrote:
Hi Serguei,
Changes look good.
Chris
On 11/12/18 8:06 PM, serguei.spit...@oracle.com wrote:
On 11/12/18 20:05, serguei.spit...@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/
<http://cr.openjdk.java.net/%7Esspitsyn/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.spit...@oracle.com
<mailto:serguei.spit...@oracle.com> <serguei.spit...@oracle.com
<mailto:serguei.spit...@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/
<http://cr.openjdk.java.net/%7Esspitsyn/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
