7u40 RFR: 8012144 - Missing memory barriers
Vladimir Kozlov
vladimir.kozlov at oracle.com
Mon Jul 8 18:29:25 PDT 2013
Looks fine to me.
_bottom is int so OrderAccess::load_acquire() is normal load on our main
platforms.
Thanks,
Vladimir
On 7/8/13 5:43 PM, David Holmes wrote:
> The issue of missing memory barriers in the GC taskqueue code was first
> flagged here:
>
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html
>
> and bug 8006971 was opened for it.
>
> There were some further background discussions that I wasn't party to
> and this all somewhat fell between the cracks for a while.
>
> A trimmed version of the original proposed patch was tested internally
> (and I believe by SAP) and that simplified patch is what is being
> proposed now, under 8012144, solely for the 7u40 update. I/we intend to
> revise the original patch for 8006971 and get that resolved properly for
> JDK 8. Meanwhile we have a critical urgency on getting this fixed in 7u40.
>
> The webrev is here:
>
> http://cr.openjdk.java.net/~dholmes/8012144/webrev.hs24/
>
> Primarily it adds a fence for platforms that require it - with platforms
> that don't opting out via the conditional compilation. In this way there
> is no performance impact on those mainline SE platforms. (A correctly
> expressed lock-free algorithm will not have platform specific fences,
> hence the intent to rework this for JDK 8.) Note this is a very low risk
> fix regardless because adding memory barriers will not introduce
> incorrect behaviour.
>
> This patch was not supplied by me, but as a follow on from the original
> work, via John Cuthbertson. So John is one of the contributors (I
> believe Axel Siebenborn is the original contributor - I need an email
> address for the attribution!) and I will actually be a Reviewer.
>
> If anyone has any concerns please raise them quickly as time is very
> much against us here.
>
> Thanks,
> David
More information about the hotspot-dev
mailing list