RFR: 8166607: G1 needs klass_or_null_acquire

[Kim Barrett]

> On Oct 18, 2016, at 11:19 AM, Erik Helin <erik.helin at oracle.com> wrote:
> 
> On 10/18/2016 04:30 PM, Kim Barrett wrote:
>>> On Oct 18, 2016, at 4:53 AM, Erik Helin <erik.helin at oracle.com> wrote:
>>> 
>>> On 2016-10-13, Kim Barrett wrote:
>>>> So what I’d like is that you just pretend for now that the comment about the
>>>> ordering in oops_on_card_xxx is actually correct.
>>>> 
>>>> The change I’m working on for JDK-8166811 eliminates that ordering problem
>>>> completely, but depends heavily on the changes here.
>>> 
>>> I've discussed this with Thomas, what do you think about pushing the
>>> fix for JDK-8166811 at the same time as this one? This patch looks good
>>> AFAICS, but I'm worried that your code will be exposed slightly
>>> different to existing bug than the current code. Given that
>>> crashes/issues resulting from these kinds of bugs often are nightmarish
>>> to track down, I'm a bit hesitant to push these patches one by one.
>>> 
>>> What do you think?
>> 
>> Sure, I can do that.
> 
> Ok, thanks! Then consider this reviewed by me, but please hold of pushing it until I (and most likely Thomas) have reviewed the patch for JDK-8166811 as well.

Good call!  While working on JDK-8166811 I discovered a bug in the proposed fix for JDK-8166607.

In the humongous case, if it bails because klass_or_null == NULL, we must re-enqueue
the card, since *card_ptr has been cleared by the time of that check.  The recorded write we’re
dealing with was stale, since klass_or_null == NULL, but there could be an in-flight real recorded
write to the same card from the allocating thread.  Our setting the card to clean could cancel
processing of that in-flight record.