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 LocalVariableTypesCalculator.leaveBinaryNode on how comparison nodes are replaced with RuntimeNodes depending on the types of sub-expressions). I doubt it is possible to guarantee these representations use a compatible slot layout, and even if there is, I think for JDK 10 it’s best to take the safe path.
Hannes > Am 25.12.2017 um 17:27 schrieb Attila Szegedi <szege...@gmail.com>: > > 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, at 4:36 PM, Hannes Wallnöfer <hannes.wallnoe...@oracle.com> >> 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 child nodes of all >> comparisons as non-optimistic, but that didn't fix the problem as those >> nodes could still have optimistic children. >> >> Hannes >
