Unsafe.storeFence produces a floating fence

Gilles Duboscq gilles.m.duboscq at oracle.com
Fri Nov 18 17:53:11 UTC 2016

Hi Andrew,

>From what i see, GraphBuilderContext.add already takes care of adding the node to the control-flow.
If you want to see how that happens, follow this call chain:
GraphBuilderContext.add -> BytecodeParser.append -> BytecodeParser.updateLastInstruction

So i think the MembarNode is correctly added in the control-flow at the point where you expect it.
I don't think that the store floats anywhere, it's fixed.

Looking at the code of actor1 i think what happens is rather the allocation of the Shell object and the initialization of x that moves down to the end of actor1 because of escape analysis.

Checking the graph in IGV might help understanding what happens.


On 18/11/16 17:42, Andrew Haley wrote:
> On 18/11/16 16:27, Doug Simon wrote:
>>> On 18 Nov 2016, at 17:20, Andrew Haley <aph at redhat.com> wrote:
>>> On 18/11/16 16:17, Doug Simon wrote:
>>>> Can you please create an issue on github for this.
>>> Oh no, something else to learn!  OK.  :-)
>> Thanks - we like using modern tools as well as email ;-)
> Ah, the kids these days...
> Anyway, I'd quite like to discuss this general issue.  If you're
> generating code, either with a Snippet or parsing bytecode, how do you
> go about creating a node that can't be moved?  You don't necessarily
> know where your immediate successors or predecessors are.  I guess you
> could search the graph and find something, but in the case of a memory
> fence all you'd like the graph builder to do is insert an immovable
> node.
> Andrew.

More information about the graal-dev mailing list