7u40 RFR: 8012144 - Missing memory barriers

[David Holmes]

On 9/07/2013 7:01 PM, Lindenmaier, Goetz wrote:
> Hi David,
>
> I'm very happy to see this change go in now.  As proposed here
> for 7u40, it would also work for our ppc64 port in jdk8.
> Yes, Axel tracked down the problem and proposed to add this
> barrier.  His email is axel.siebenborn at sap.com.

Thanks for the info.

> Actually, I would use X86 instead of IA32 || AMD64.
> (maybe add #include utilities/macros.hpp, but X86 is
> defined before all uses of taskqueue.hpp. I tested this
> on linux.)

Unfortunately I don't have time to make this change and re-do the 
testing that has already been done.

Thanks,
David

> Best regards,
>    Goetz.
>
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Dienstag, 9. Juli 2013 02:43
> To: hotspot-dev developers
> Cc: Lindenmaier, Goetz; John Cuthbertson
> Subject: 7u40 RFR: 8012144 - Missing memory barriers
>
> 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
>