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

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
>>> post_barrier, ignoring the CAS result. In some cases, notably
>>> contended CAS spin-loops, we fail the CAS a lot, and thus go for a
>>> post_barrier excessively. Instead, we can conditionalize on the
>>> result of the store itself, and put the post_barrier 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