fixes for barriers on constant oops

[Roman Kennke]

Hi Roland,

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?
- comparing classes: are we sure this is still optimized to
a.klass==b.klass?

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);


Other than that, looks good to me.

Roman

Am 27.06.2017 um 10:04 schrieb Roland Westrelin:
> http://cr.openjdk.java.net/~roland/shenandoah/barrier-on-const-fixes/webrev.00/
>
> The patch includes:
>
> - missing barriers on constant oops
>
> - a small fix for compare and exchange in x86_64.ad: setting the cost to
>   1000 is apparently not sufficient as I found the CAE could be emitted
>   without the barriers
>
> - a change to the implementation of acmp so now instead of building:
>
> if (a != b) {
>   a = rb(a);
>   b = rb(b);
> }
> if (a == b) {
>
> } else {
>
> }
>
> at parse time and letting the compiler possibly optimize it to:
>
> if (a != b) {
>   a = rb(a);
>   b = rb(b);
>   if (a != b) {
>   } else {
>   }
> } else {
>
> }
>
> C2 builds the second form at parse time. It's not as easy to plug the
> new graph shape where there are pointer comparisons (in intrinsics). So
> other pointer comparisons now all use:
>
> a = wb(a);
> b = wb(b);
>
> if (a == b) {
>
> } else {
>
> }
>
> - another fix to the write barrier code once expanded when it's applied
>   to a constant oop
>
> - some unrelated fixes
>
> Roland.