RFR: 8031703 - Missing post-barrier in ReferenceProcessor

Thomas Schatzl thomas.schatzl at oracle.com
Tue Feb 4 12:45:07 UTC 2014

Hi Per,

On Tue, 2014-02-04 at 11:15 +0100, Per Liden wrote:
> Hi Tony,
> On 2014-02-04 04:20, Tony Printezis wrote:
> > Hi Per,
> >
> > I went over the code one more time and I think your assessment is 
> > correct. But, could I recommend that you at least add a comment to 
> > that effect where the DiscoveredListIterator iter(...) is declared? 
> Hmm, which one? The iterator is instanciated in several places. I'd 
> suggest I add a comment like this to the remove() function, where the 
> pre-barriers is omitted. Ok?
> > Also, maybe, rename the discovered_list_needs_barrier parameter as 
> > ..._needs_post_barrier to make its role a bit more explicit?
> Good idea, will add "post".
> Updated webrev here: http://cr.openjdk.java.net/~pliden/8031703/webrev.1/

As far as I can tell, the change looks good to me.

There are some minor comments about related code:

In G1CollectedHeap::ref_processing_init(), there seems to be a
copy&paste error when initializing the STW ref processor. I.e. the
discovered_list_needs_post_barrier parameter is false, but the comment
still reads:

    // Setting next fields of discovered
    // lists requires a barrier.

which seems odd since we pass false to the parameter.


More information about the hotspot-gc-dev mailing list