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

[Roland Westrelin]

> Ok, but all the verification code happens under #ifdef ASSERT so that is
> only going to change behaviour in non-production builds right?
>
> i.e. the important change is the one to the meet code?

Yes, to both.

> 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.

Roland.