RFR: 8166811: Missing memory fences between memory allocation and refinement

[Kim Barrett]

> On Nov 17, 2016, at 12:07 PM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi Kim,
> 
> 
> 
> On Thu, 2016-11-17 at 12:28 +0100, Thomas Schatzl wrote:
>> Hi Kim,
>> 
>> 
> [...]
> 
>> So the check in g1RemSet.cpp
>> 
>>  597   if (!r->is_old_or_humongous()) {
>> 
>> may filter the card out wrongly when processing the card from thread
>> B
>> as far as I can see.
>> 
>> That's why I remarked about only being able to filter out using
>> is_young() here. For the refinement thread, "top" is current (after
>> the
>> fence), but the region type not (may still be "Free" until the
>> refinement "synchronizes" with thread A in some way), doesn't it?
>> 
>> The change to "top" must have been observed already after the fence
>> (in
>> line 684) though and is safe to use (the allocation of the TLAB for
>> thread B sets top using appropriate barriers, and the refinement will
>> synchronize with whatever thread B set).
>> 
>> Probably I am overlooking something about how the type of region X
>> set by thread A can be visible to refinement if it only
>> "synchronizes" with thread B (that did not write the type of region
>> X).
> 
>   I think it is good. Erik gave me the hint (and probably you already
> mentioned it somewhere). That case can only happen for young regions,
> and we can ignore them.
> 
> We only allocate into humongous regions once.
> 
> Thanks,
>   Thomas

Kudos to Erik of helping you answer your question.  I was still struggling
with understanding the scenario you were trying to describe.