7u40 RFR: 8012144 - Missing memory barriers

[Lindenmaier, Goetz]

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.

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.)

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