RFR: Fix and rewrite update-refs barrier selector
Aleksey Shipilev
shade at redhat.com
Wed Jan 24 17:03:14 UTC 2018
On 01/24/2018 05:31 PM, Aleksey Shipilev wrote:
> 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/
Actually, let's rewrite the damn fragile thing:
http://cr.openjdk.java.net/~shade/shenandoah/traversal-regr-1/webrev.02/
-Aleksey
More information about the shenandoah-dev
mailing list