RFR: Fix Traversal GC regression

Aleksey Shipilev shade at redhat.com
Wed Jan 24 16:31:53 UTC 2018


After Traversal GC commit, normal cycle on Compiler.compiler fails within:

V  [libjvm.so+0x153c713]  oop ShenandoahHeap::evac_update_oop_ref<unsigned int>(unsigned int*,
bool&)+0x333
V  [libjvm.so+0x1539082]  ShenandoahBarrierSet::write_ref_array(HeapWord*, unsigned long)+0x852
V  [libjvm.so+0x133be02]  void ObjArrayKlass::do_copy<unsigned int>(arrayOop, unsigned int*,
arrayOop, unsigned int*, int, Thread*)+0x142
V  [libjvm.so+0x133932b]  ObjArrayKlass::copy_array(arrayOop, int, arrayOop, int, int, Thread*)+0x72b
V  [libjvm.so+0xf23325]  JVM_ArrayCopy+0x1e5

The troubling bit is why do we even get here:

  inline void do_oop_work(T* p) {
    oop o;
    if (STOREVAL_WRITE_BARRIER) {
      bool evac;
      o = _heap->evac_update_oop_ref(p, evac); <--- ????
      if ((ALWAYS_ENQUEUE || evac) && !oopDesc::is_null(o)) {
        ShenandoahBarrierSet::enqueue(o);
      }
    } else {
      o = _heap->maybe_update_oop_ref(p);
    }
    if (UPDATE_MATRIX && !oopDesc::is_null(o)) {
      _heap->connection_matrix()->set_connected(p, o);
    }
  }

It happens because the condition in selector is wrong:
  http://cr.openjdk.java.net/~shade/shenandoah/traversal-regr-1/webrev.01/

(Note the symmetry against the branch at L223.

Testing: failing Compiler.compiler

-Aleksey



More information about the shenandoah-dev mailing list