RFR: JDK-8211279: Verify missing object equals barriers

[Aleksey Shipilev]

On 10/03/2018 02:04 PM, Roman Kennke wrote:
> The problem is that it would get false positive *in most cases*. With
> the solution that I proposed, one would do a run on purpose to catch
> missing eq barriers, and find all the relevant places *before it
> actually blows up*. The solution you propose would lead to rare
> headscratching failures instead. I'd rather prefer the explicit
> flag-controlled verification.

That is what we actually do in Shenandoah: we have the test runs with this verification enabled.
This captures all the missing acmp barriers at once, which is very handy for maintenance, for
example when doing massive upstream merges.

It is the question whether you want to assert the missing barriers statically, e.g. reporting all
risky comparisons as failures, or you want to do this dynamically by checking the actual failures.
IIRC, in Shenandoah, the frequency of actually hitting the acmp slowpath for false negative handling
(i.e. both sides point to the different copies of the same object) is way too low for dynamic way to
be reliable, even in "aggressive" / "move everything all the time" mode.

I can get by Erik's idea that in some cases the comparisons are provably safe from the code
inspection. In these places, we have unsafe_equals that clearly captures that intent, and can be
used on high-performance paths. Think about unsafe_equals as the brother of RawAccess; in fact,
maybe it should be called raw_equals :)

-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20181003/651ba0c1/signature.asc>