RFR (S) 8019968: Reference CAS induces GC store barrier even on failure (original) (raw)

Vladimir Kozlov vladimir.kozlov at oracle.com
Fri Jul 31 03:03:02 UTC 2015

I think the test is wrong. It should be:

if_then(load_store, BoolTest::eq, oldval, PROB_STATIC_FREQUENT);

Thanks, Vladimir

On 7/29/15 2:57 AM, Aleksey Shipilev wrote:

On 07/29/2015 12:24 PM, Andrew Dinn wrote:

On 29/07/15 09:58, Aleksey Shipilev wrote:

I would like to suggest a fix for: https://bugs.openjdk.java.net/browse/JDK-8019968

In short, current reference CAS intrinsic blindly emits postbarrier, ignoring the CAS result. In some cases, notably contended CAS spin-loops, we fail the CAS a lot, and thus go for a postbarrier excessively. Instead, we can conditionalize on the result of the store itself, and put the postbarrier only on success path: http://cr.openjdk.java.net/~shade/8019968/webrev.01/ More performance results here: http://cr.openjdk.java.net/~shade/8019968/notes.txt Nice! The code looks fine and your test results are very convincing. I'll be interested to see how this looks on AArch64. Thanks Andrew! The change passes JPRT, so AArch64 build is available. The benchmark JAR mentioned in the issue comments would run without intervention, taking around 40 minutes. You are very welcome to try, while Reviewers are taking a look. I can do that only next week. That said, I am afraid you still need a Reviewer! That reminds me I haven't spelled out what testing was done: * JPRT on all open platforms * Targeted benchmarks * Eyeballing the generated x86 assembly Thanks, -Aleksey

More information about the hotspot-compiler-dev mailing list