RFR: 8031703 - Missing post-barrier in ReferenceProcessor
thomas.schatzl at oracle.com
Tue Feb 4 04:45:07 PST 2014
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
// 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