RFR(s): 8029255: G1: Reference processing should not enqueue references on the shared SATB queue
thomas.schatzl at oracle.com
Fri Nov 29 11:52:50 UTC 2013
On Fri, 2013-11-29 at 12:37 +0100, Thomas Schatzl wrote:
> 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.
> 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
More information about the hotspot-gc-dev