fixes for barriers on constant oops

Roman Kennke rkennke at redhat.com
Tue Jun 27 09:09:30 UTC 2017


Am 27.06.2017 um 11:08 schrieb Roland Westrelin:
> Hi Roman,
>
>> of the paths with write-barrier-cmp in library_call.cpp, there are only
>> two cases:
>> - comparing threads. is this likely to be a hot path?
> I have no idea. Given there's an intrinsic I suppose it can be. Anyway,
> using write barriers make the code a lot simpler so unless we find
> there's something to gain here, I'd like to keep the code as simple as
> possible.
>
>> - comparing classes: are we sure this is still optimized to
>> a.klass==b.klass?
> Likely not. I'll double check that. But I'ld like to push the changes I
> have so far.
>
>> Is this correct?
>>
>> @@ -992,16 +992,16 @@
>>                  region->set_req(2, membar->in(0));
>>                  membar->set_req(0, phase->C->top());
>>                  phase->record_for_igvn(region);
>>                  phase->record_for_igvn(membar);
>>                }
>> - }
>>              return true;
>>            }
>>          }
>>        }
>>      }
>> + }
>>    } else if (in(1)->is_ShenandoahBarrier()) {
>>      // For this pattern:
>>      // if (a != b) {
>>      //   a = read_barrier(a);
>>      //   b = read_barrier(b);
> The current code looks broken to me. It makes all those validation
> checks but returns true even if one of the check fails.
>
> Roland.

Ok then.

Roman



More information about the shenandoah-dev mailing list