JDK-8340183 introduced a regression: `ShenandoahBarrierSetC2::is_gc_barrier_node` is now answering `false` for the actual `ShenandoahLoadReferenceBarrierNode`. This was found with deeper JFR testing:

```
$ CONF=linux-x86_64-server-fastdebug make test TEST=jdk/jfr/api/consumer/ TEST_VM_OPTS="-XX:+UseShenandoahGC" JTREG=REPEAT_COUNT=100

...

STDOUT:
 1351 DecodeN === _ 2649 [[ 1023 ]] #java/util/ArrayList$Itr (java/util/Iterator):NotNull:exact *,iid=577 Oop:java/util/ArrayList$Itr (java/util/Iterator):NotNull:exact *,iid=577 !jvms: Collections$UnmodifiableCollection$1::next @ bci:1 (line 1079) MetadataWriter::makeAnnotation @ bci:53 (line 217)
 1023 ShenandoahLoadReferenceBarrier === _ 1351 [[ 668 ]] Oop:java/util/ArrayList$Itr (java/util/Iterator):NotNull:exact *,iid=577 !jvms: Collections$UnmodifiableCollection$1::next @ bci:1 (line 1079) MetadataWriter::makeAnnotation @ bci:53 (line 217)
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (/home/shade/trunks/jdk/src/hotspot/share/opto/escape.cpp:4577), pid=2394913, tid=2394997
# assert(false) failed: EA: missing allocation reference path
#
```

This looks intermittent, and that probably explains why the full test run in JDK-8340183 have not found the issue.