Thanks for the review, Attila.
I didn’t look at the contents of the local slots. I think the root of the
problem is that the comparison is represented as RuntimeNode in some cases and
as BinaryNode in others, and it can switch between the two between optimistic
recompilations (see
A sad +1. I too wish this were easier to solve. Can you point me to the code
parts that cause differences in local slot assignment? I guess I could try to
figure it out myself from that terrible expression in the test, but if you have
a quick explanation…
Thanks,
Attila.
> On Dec 21, 2017,
+1
> On Dec 21, 2017, at 11:36 AM, Hannes Wallnöfer
> wrote:
>
> Please review:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8193567
> Webrev: http://cr.openjdk.java.net/~hannesw/8193567/webrev.00/
>
> I’ve tried finding a smaller fix like just tagging the
Please review:
Bug: https://bugs.openjdk.java.net/browse/JDK-8193567
Webrev: http://cr.openjdk.java.net/~hannesw/8193567/webrev.00/
I’ve tried finding a smaller fix like just tagging the child nodes of all
comparisons as non-optimistic, but that didn't fix the problem as those nodes
could