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