RFR: Hole in CAS barrier when using traversal heuristics

[Roman Kennke]

Am 25.01.2018 um 20:05 schrieb Zhengyu Gu:
> 
>>>>
>>>> Hi Zhengyu,
>>>>
>>>> I am not sure what you mean by 'evacuates target and exchange object,
>>>> but not the field' .. clearly the target object needs to be 
>>>> evacuated, because we only write to to-space (write-barrier). Also, 
>>>> the exchange object needs to be evacuated, to ensure we end up only 
>>>> with to-space references in fields (storeval-barrier). What do you 
>>>> mean by evacuation of 'the field' ? The target field is part of the 
>>>> target object.
>>>
>>> There is an example:
>>> http://hg.openjdk.java.net/shenandoah/jdk10/file/6183a72bd5c2/src/hotspot/share/prims/unsafe.cpp#l1020 
>>>
>>>
>>> the addr points a field in object, that might not be evacuated and I 
>>> think you do have to enqueue it, as the object may be gray.
>>
>> addr is a field in p, which is in to-space by the WB a few lines 
>> above. This should be good. x is the exchange value, also evacuated by 
>> the storeval barrier. So all should be fine.
> 
> Yes, p and x are fine, but the field (e.g. an object) to be swapped out, 
> may still in cset,

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.

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

> 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