RFR: 8006971: More missing barriers in taskqueues for RMO architectures

[Vladimir Danushevsky]

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

JDK7u40 fix for the same issue is located here:
http://cr.openjdk.java.net/~dholmes/8012144/webrev.hs24/


Initially we planned to port same solution to JDK8 however after reviewing the algorithm more we've started questioning a need for a full fence in between 'age' and 'bottom' elements. Since the intent is to keep 'bottom' memory reference from being executed before 'age' would a LoadLoad barrier (which in many cases is a cheaper solution) be sufficient? If so, the webrev below could possible be an adequate solution.

http://cr.openjdk.java.net/~vladidan/8006971/webrev.00/

We have tested both cases (fence and LL) on a hexa-core Power5 box running several test suites that currently expose the problem. The results are positive.

As a side note - 
perhaps it is possible to eliminate age/bottom potential reordering by loading both simultaneously through an Atomic class method. That would require though some structural changes to the layout of TaskQueueSuper class to align both fields together and ensure proper integer alignment (depending on 32/64-bit port), therefore this solution is less practical for the short term.

Thanks,
Vlad