elision of volatile field load with empty usages

Lukas Stadler lukas.stadler at jku.at
Wed Feb 19 14:46:44 PST 2014


Hm... I think that the following argument can be made:
If the value that is read has no influence on the method's results or the method's side effects, then there is no way to tell if the operations were reordered or not.
As the JMM specifies only the observed effects, and not the position of the memory barriers, removing the barrier completely should be fine in this case.

- Lukas

On 16 Feb 2014, at 14:19 , Garcia Gutierrez Miguel Alfredo <miguelalfredo.garcia at epfl.ch> wrote:

> 
> In general, a field-load with empty usages on a definitely-non-null is candidate for elision.
> 
> However, what about volatile fields? Currently, elision is done (see excerpt below)
> 
>  public final class LoadFieldNode extends AccessFieldNode implements Canonicalizable, VirtualizableRoot {
>      ...
>      public Node canonical(CanonicalizerTool tool) {
>          if (usages().isEmpty() && (isStatic() || ObjectStamp.isObjectNonNull(object().stamp()))) {
>              return null;
>          }
>          ...
>      ...
> 
> Instead, the JMM leads me to believe the "volatile-effect" should remain, even if the actual loaded value isn't needed.
> 
> To get that effect without actually loading anything (this is another, related question) Is it possible to have memory brackets without any intervening ReadNode (or WriteNode)? ("memory brackets" as in the snippet below, reproduced from HotSpotLoweringProvider, LoadFieldNode case)
> 
>            if (loadField.isVolatile()) {
>                MembarNode preMembar = graph.add(new MembarNode(JMM_PRE_VOLATILE_READ));
>                graph.addBeforeFixed(memoryRead, preMembar);
>                MembarNode postMembar = graph.add(new MembarNode(JMM_POST_VOLATILE_READ));
>                graph.addAfterFixed(memoryRead, postMembar);
>            }
> 
> 
> --
> Miguel Garcia
> Swiss Federal Institute of Technology
> EPFL - IC - LAMP1 - INR 328 - Station 14
> CH-1015 Lausanne - Switzerland
> http://lamp.epfl.ch/~magarcia/



More information about the graal-dev mailing list