RFR: Hole in CAS barrier when using traversal heuristics

[Roman Kennke]

Am 25.01.2018 um 20:55 schrieb Zhengyu Gu:
>>> BTW, what's reason it has to be to-space object? can it be evacuated 
>>> during processing SATB buffers, or by storeval_barrier()?
> Sorry, I am not clear on my question, which should be: why should only 
> enqueue to-space object during conc-traversal gc?
> 
>>
>> 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.
> 
> I understand above reasons.
> 
> But these do not apply to object to be enqueued to satisfy SATB 
> protocol, since we do not write or update this object, but just to make 
> sure it should be marked. If I understand correctly, this object has to 
> be in to-space at the end of GC cycle with traversal gc. however, I 
> don't see why it has to be to-space object to be enqueued, can it be 
> evacuated when it is processed?

The storeval barrier has two purposes: one is to ensure consistency vs. 
'update-refs' (traversal updates references). The other is to ensure 
consistency vs traversal of the heap (e.g. 'marking'). If it needs to 
write-barrier the object anyway (to ensure update-refs consistency), 
then we can just as well make this an invariant. Then we can avoid 
reading the fwd ptrs in the GC thread.

> BTW, do you want to take over this one?

Ok, can do it. Do you happen to have a reproducer?

Roman