7u40 RFR: 8012144 - Missing memory barriers
david.holmes at oracle.com
Tue Jul 9 18:07:26 PDT 2013
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.
> Best regards,
> -----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:
> 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:
> 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.
More information about the hotspot-dev