RFR: Hole in CAS barrier when using traversal heuristics

[Roman Kennke]

Am 25.01.2018 um 21:02 schrieb Zhengyu Gu:
>>
>> No. The field is not an object. The field is a reference, and belongs 
>> to p, and points to another object (e.g. x). It is not an object by 
>> itself and thus cannot be evacuated or such.
> Sorry, my bad writing, it is a reference to an object that may still in 
> from-space.

Ok. Yes.

>>   and it is enqueued by
>>> oopDesc::atomic_compare_exchange_oop() 
>>> (http://hg.openjdk.java.net/shenandoah/jdk10/file/3c12448ec444/src/hotspot/share/oops/oop.inline.hpp#l407), 
>>> then hit assertion failure here:
>>>
>>> http://hg.openjdk.java.net/shenandoah/jdk10/file/3c12448ec444/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp#l464 
>>>
>>>
>>> hs_err: https://paste.fedoraproject.org/paste/isPRNXG6PqaPgx9a18IA4w
>>
>> Hmm, ok. This is a problem in 
>> oopDesc::::atomic_compare_exchange_oop(). It calls 
>> write_ref_field_pre(), which it shouldn't do. By our design, it should 
>> call storeval_barrier() instead, which does the right thing. However, 
>> this is going to change once we merge from upstream...
> 
> Sorry, call storeval_barrier() on what? my understanding this that, you 
> have to apply SATB barrier on swapped out *old* value, which is this 
> write_ref_field_pre() does, no?

We have a little naming problem here. While we're using G1's SATB buffer 
to enqueue objects, the traversal GC algorithm is *not* SATB-based. It 
is incremental-update-based, which is kindof the opposite of SATB. (one 
could call it 'snapshot-at-the-end' (-of-traversal). Instead of enqueing 
the previous values on stores, it enqueues the *new* values on stores. 
This is why the storeval barrier can do both enqueue (for i-u) and WB 
(for update-refs-consistency) in one swoop.

I hope this clarifies it. ?

Roman