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:52 +0100, Thomas Schatzl wrote:
> 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).

Scratch that, this is not true.

Sorry for the noise,
  Thomas