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.
Gilles
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