RFR(s): 8029255: G1: Reference processing should not enqueue references on the shared SATB queue

[Thomas Schatzl]

Hi,

On Fri, 2013-11-29 at 12:37 +0100, Thomas Schatzl wrote:
> Hi,
> 
>   some comments:
> 
> In this process we loose the previous values too, that's why the code
> cannot just apply the normal barrier - before activating the shared
> reference queue in 8029162 it was not a problem because the "old"
> references were dropped immediately when trying to add.
> 
> It seems that this is not an issue in regards to SATB as these fields
> are handled somewhat specially always anyway.

and

> Other issues:
> - (this is more a question than an issue)
> DiscoveredListIterator::make_active() has some special handling for
> setting the next field of java.lang.Reference. In particular it does not
> call the post-barrier because this will fail CT verification in G1.
> What's the difference between that field and the discovered field in
> that respect? Also the original code executed the post-barrier on the
> next field (e.g. referenceProcessor.cpp:366), so if there were a
> problem, it should already occur, shouldn't it?

Looking at ReferenceProcessor::make_active() again, it calls the
pre_barrier on the new value. Maybe this is what should be done when
setting the discovered field of the references too to make SATB
happy(-ier) (the old value is, as mentioned, overwritten during
collection).

Thomas