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