RFR: 8166811: Missing memory fences between memory allocation and refinement
erik.helin at oracle.com
Thu Nov 17 17:28:28 UTC 2016
On 11/16/2016 01:00 AM, Kim Barrett wrote:
>> On Nov 15, 2016, at 5:26 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
>> On Thu, 2016-11-10 at 13:20 -0500, Kim Barrett wrote:
>>>> On Nov 8, 2016, at 7:52 AM, Thomas Schatzl <thomas.schatzl at oracle.c
>>>> om> wrote:
>>>> On Tue, 2016-10-25 at 19:13 -0400, Kim Barrett wrote:
>>>> - assuming this works due to other synchronization,
>>> This is the critical point. There *is* synchronization there.
>> Okay, thanks. I just wanted to make sure that we are aware of that we
>> are using this other synchronization here.
>> Thanks. Again I was mostly worried about noting this reliance on
>> previous synchronization down somewhere, even if it is only the mailing
>> It may be useful to note this in the code too. This would save the next
>> one working on this code looking through old mailing list threads.
>> Maybe I am a bit overly concerned about making sure that these thoughts
>> are provided in the proper place though. Or maybe everyone thinks that
>> everything is clear :)
> I've updated some comments to mention that external synchronization.
> full: http://cr.openjdk.java.net/~kbarrett/8166811/webrev.01/
First of all, thanks for doing this tricky work. One initial comment:
659 // Iterate over the objects overlapping the card designated by
660 // card_ptr, applying cl to all references in the region. This
661 // is a helper for G1RemSet::refine_card, and is tightly coupled
662 // with it.
In the first sentence you mention the now removed argument card_ptr.
Maybe just reword this to "Iterate over the objects covered by the
memory region, applying cl to all references in the region"?
I will have to sleep on this review, the synchronization to make all of
this hold together seems to be all over place :) (not your fault,
pre-existing). I will continue this review tomorrow morning with a fresh
> incr: http://cr.openjdk.java.net/~kbarrett/8166811/webrev.01.inc/
> Also, since this set of changes is rather intertwined with the changes
> for 8166607, here is a combined webrev for both:
> I think I'll do as Erik suggested and push the two together.
More information about the hotspot-dev