fixes for barriers on constant oops
Roland Westrelin
rwestrel at redhat.com
Tue Jun 27 09:08:35 UTC 2017
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.
More information about the shenandoah-dev
mailing list