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

[Andrew Haley]

On 24/07/2020 22:07, Andrew Dinn wrote:
> 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 ;-)

Yeah, OK. Of course I'm not super keen on a change in C2 which fixes
a bug that we can't reproduce, but it'll have to do.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671