[8u] RFR: 8240676: Meet not symmetric failure when running lucene on jdk8

[Andrew Dinn]

On 24/07/2020 13:59, Roland Westrelin wrote:
>> That may well change behaviour for some programs as meets are computed
>> outside of the changed verification path. I'd like to assume the
>> benefits of improving type accuracy override the risk. Do you think that
>> is justified? (one might argue that improved type accuracy is not always
>> better, especially for speculative info where avoiding the erasure might
>> enable optimizations not previously attempted).
> 
> I would say both benefit and risk are small. Without the speculative
> type change, we'll hit failures in the new verification code so some
> other tweak would have to be done to work around them. Not sure what
> could be done but that would likely be as risky. Or only the actual fix
> is backported and the new verification code is left out. Then the
> speculative type fix is not required. But a regression wouldn't be
> caught either.
That's a good enough justification for me. Ship it!

. . . well, modulo maintainer approval ;-)

regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill