RFR: 8078743: AARCH64: Extend use of stlr to cater for volatile object stores

[Vladimir Kozlov]

First, thank you for extensive comments - they help.

Second, does it really help? I don't see any numbers.

Next pattern (returning NULL or false) is repeater several times. May be make separate function for it.


+    if (opcode != Op_MemBarRelease) {
+      if (opcode != Op_MemBarCPUOrder)
+        return NULL;
+      MemBarNode *parent = parent_membar(leading);
+      if (!parent || !parent->Opcode() == Op_MemBarRelease)
+        return NULL;
+    }

Can you replace retry_feed: with while(cond) ?

Next could be one line Node *x = training
+    Node *x;
+    // the Mem feed to the membar should be a merge
+    x = trailing->in(TypeFunc::Memory);

Thanks,
Vladimir

On 7/29/15 3:55 AM, Andrew Dinn wrote:
> The following webrev is a follow-on to the fix posted for JDK-8078263.
> The earlier fix optimized *non-object* volatile puts/gets to use
> stlr/ldar and elide the associated leading/trailing dmb instructions.
> This one extends the previous optimization to cover volatile object puts.
>
>    http://cr.openjdk.java.net/~adinn/8078743/webrev.03/
>
> The fix involves identifying certain Ideal Graph configurations in which
> generation of leading and trailing dmb can be avoided in favour of
> generating an stlr instruction. As a consequence the fix is sensitive to
> the current GC configs and also to whether the value being written is
> null, potentially null or known notnull. I have tested it using 5 GC
> configs:
>
>    G1GC
>    CMS+UseCondCardMark
>    CMS-UseCondCardMark
>    Parallel+UseCondCardMark
>    Parallel-UseCondCardMark
>
> The last two configs are much of a muchness as regards what the patch
> code does since with Parallel (or Serial) GC the patch code does not
> need to look at the code which does the card mark -- but I tested
> against both just to be sure.
>
> Testing involved
>
>    i) eyeballing the code generated for normal and unsafe volatile puts
> with null, possibly null and notnull values
>
>    ii) exercising a large program (build and run sample project in
> netbeans) and eyeballing the code generated for methods of ConcurrentHashMap
>
>    iii) running the full jcstress suite
>
> Comments and reviews very welcome
>
> n.b. I have a 3rd patch queued which performs a similar optimization for
> CAS operations (drop the dmbs in favour of an ldaxr/stlxr pair).
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in UK and Wales under Company Registration No. 3798903
> Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
> (USA), Michael O'Neill (Ireland)
>