ShenandoahBS::AccessBarrier::oop_store_in_heap ignores AS_NO_KEEPALIVE

Studying the hotpath in final-mark reference processing code, this thing is hot:

void DiscoveredListIterator::enqueue() {
  HeapAccess<AS_NO_KEEPALIVE>::oop_store_at(_current_discovered,
                                            java_lang_ref_Reference::discovered_offset,
                                            _next_discovered);
}

Note it seems to pass AS_NO_KEEPALIVE. However, Shenandoah ignores that when handling the oop_store_at, and does useless enqueue dance.

Dirty fix:

diff -r 6f14d52d5e10 src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp
--- a/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp Fri Mar 15 13:01:30 2019 +0100
+++ b/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp Mon Mar 18 14:51:24 2019 +0100
@@ -228,15 +228,24 @@
     static void oop_store_in_heap(T* addr, oop value) {
       ShenandoahBarrierSet::barrier_set()->write_ref_field_pre_work(addr, value);
       Raw::oop_store(addr, value);
     }
 
+ template <typename T>
+ static void oop_store_in_heap_no_keepalive(T* addr, oop value) {
+ Raw::oop_store(addr, value);
+ }
+
     static void oop_store_in_heap_at(oop base, ptrdiff_t offset, oop value) {
       base = ShenandoahBarrierSet::barrier_set()->write_barrier(base);
       value = ShenandoahBarrierSet::barrier_set()->storeval_barrier(value);
 
- oop_store_in_heap(AccessInternal::oop_field_addr<decorators>(base, offset), value);
+ if ((decorators & AS_NO_KEEPALIVE) != 0) {
+ oop_store_in_heap_no_keepalive(AccessInternal::oop_field_addr<decorators>(base, offset), value);
+ } else {
+ oop_store_in_heap(AccessInternal::oop_field_addr<decorators>(base, offset), value);
+ }
     }
 
     template <typename T>
     static oop oop_atomic_cmpxchg_in_heap(oop new_value, T* addr, oop compare_value);
 
On stress tests, it improves reference-processing time from 205 ms to 165 ms.