acmp/cas retries and null arguments

[Roman Kennke]

Am Dienstag, den 13.09.2016, 16:06 +0200 schrieb Aleksey Shipilev:
> Hi,
> 
> I have a question about read barriers and null handling. It seems to
> me
> that in acmp/cas comparison, if one of the arguments is null, and
> comparison had failed, this means it had failed for good, i.e. it is
> never a false negative. I.e. comparing the non-null from-copy with
> null
> produces the same result as comparing the non-null to-copy with null.
> Comparing null with null would not trigger a false negative.

This is correct.

> If so, I wonder if we can coalesce the null checking code in acmp/cas
> retries with the actual retries, instead of jumping over the barrier.
> We
> currently do, e.g. in acmp (in some weird linear pseudo-assembly):
> 
> acmp(%a, %b):
>   test %a, %b
>   je <true>
> 
>     test %a, %a
>     je <anull>
>     mov %a, (%a - 8);
>     anull:
> 
>     test %b, %b
>     je <bnull>
>     mov %b, (%b - 8);
>     bnull:
> 
>     test %a, %b;
>     je <true>
> 
>     ret false;
> 
>   true:
>   ret true;
> 
> ...while instead we could generate:
> 
> acmp(%a, %b):
>   test %a, %b
>   je <true>
> 
>     test %a, %a
>     je <false>  // %a is null, guaranteed "false"
>     mov %a, (%a - 8);
> 
>     test %b, %b
>     je <false>  // %b is null, guaranteed "false"
>     mov %b, (%b - 8);
> 
>     test %a, %b;
>     je <true>
> 
>     false:
>     ret false;
> 
>   true:
>   ret true;
> 
> This saves read barriers if one of the arguments is not null.

Right.
C2 should avoid generating the special acmp and cas barriers if one of
the args is *known* to be null.

It's a little more involved if it determines at runtime that one is
null. I'd be happy to see it optimized though :-)

Roman