RFR: Hole in CAS barrier when using traversal heuristics

Zhengyu Gu zgu at redhat.com
Thu Jan 25 19:55:06 UTC 2018


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

BTW, do you want to take over this one?

Thanks,

-Zhengyu






> 
> Roman
> 


More information about the shenandoah-dev mailing list