RFR: 8166607: G1 needs klass_or_null_acquire

[Kim Barrett]

<private>

> On Oct 13, 2016, at 6:11 AM, Erik Helin <erik.helin at oracle.com> wrote:
> I agree that your change doesn't make it worse and I know that you will
> work on JDK-8166711. The problem is that I get headache enough from
> reasoning about these kind of issues, so I'm having a hard time
> reviewing this patch and trying to figure if it is correct as it is. If
> I also have to take into account that some known issues will be fixed,
> then it becomes *really* hard for me to verify this patch :(
> 
> If you plan on working on JDK-8166711, is there any chance you can send
> out the patch for that issue first, and then this patch can be
> rebased on top of that work? I will of course review the patch for
> JDK-8166711 as well.

I'm pretty sure I don't want to analyze the changes I'm thinking about
making for JDK-8166711 against the old (pre-fix for JDK-8166607) code.
So re-ordering the changes doesn't really work for me.

That's why I suggested I could, in the webrev under review, add an
OrderAccess::loadload() somewhere between the top() access and the
is_young() check to ensure the ordering there, as a temporary
workaround for JDK-8166711.  Or you could pretend it's there when
reviewing (which is what I did when writing it).

I think the best place for that loadload is right after the call to
top(); it's not needed on the in-GC scan_top branch.  But it can go
anywere after there until before the call to is_young().