RFR: Hole in CAS barrier when using traversal heuristics

[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.

> 
>   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?


Thanks,

-Zhengyu

> 
>> BTW, what's reason it has to be to-space object? can it be evacuated 
>> during processing SATB buffers, or by storeval_barrier()?
> 
> We have two reasons for forcing to-space objects:
> - We must only ever write to to-space objects for consistency
> - We must only ever store to-space objects into fields, because the GC 
> threads that concurrently update fields may already have visited it. If 
> Java threads were writing from-space objects we may end up with 
> pointers/fields to from-space objects after GC.
> 
> Roman
>