RFR: Protect C2 matchers with UseShenandoahGC

[Roman Kennke]

Yes that makes sense. Please go!

In the (not so) long run, we need to think hard about how to deal with
this sort of stuff. We will get a good code generation API soonish (I
hope). But that will not and probably can not really cover GC specific
optimization passes and support code, because those need to be hooked
up all over the place in C2.

Roman

On Mon, Feb 19, 2018 at 6:17 PM, Aleksey Shipilev <shade at redhat.com> wrote:
> These matchers are used in shared code to act on Shenandoah code. While it works, because they match
> the particular TLS+offset that is Shenandoah-specific, it is still fragile. I would prefer us to
> chicken out when Shenandoah is disabled:
>
> diff -r 397c505d68f5 src/hotspot/share/opto/shenandoahSupport.cpp
> --- a/src/hotspot/share/opto/shenandoahSupport.cpp      Mon Feb 19 16:58:32 2018 +0100
> +++ b/src/hotspot/share/opto/shenandoahSupport.cpp      Mon Feb 19 18:15:37 2018 +0100
> @@ -557,6 +557,9 @@
>  }
>
>  bool ShenandoahWriteBarrierNode::is_evacuation_in_progress_test(Node* iff) {
> +  if (!UseShenandoahGC) {
> +    return false;
> +  }
>    assert(iff->is_If(), "bad input");
>    if (iff->Opcode() != Op_If) {
>      return false;
> @@ -587,6 +590,9 @@
>  }
>
>  bool ShenandoahWriteBarrierNode::is_gc_state_load(Node *n) {
> +  if (!UseShenandoahGC) {
> +    return false;
> +  }
>    if (n->Opcode() != Op_LoadUB && n->Opcode() != Op_LoadB) {
>      return false;
>    }
>
> Testing: hotspot_fast_gc_shenandoah
>
> Thanks,
> -Aleksey
>