Potential Graal Regression: The location argument could not be resolved to a constant.

Tue May 27 14:05:23 UTC 2014

On Tue, May 27, 2014 at 3:48 PM, Gilles Duboscq <duboscq at ssw.jku.at> wrote:
> Hello Stefan,
>
> I had a look at your problem.
> From what i can see the problem happens at this call stack:
>
> com.oracle.graal.truffle.FrameWithoutBoxing.getObjectUnsafe(FrameWithoutBoxing.java:84)
> com.oracle.graal.truffle.FrameWithoutBoxing.getObject(FrameWithoutBoxing.java:68)
> com.oracle.truffle.api.frame.FrameUtil.getObjectSafe(FrameUtil.java:38)
> som.interpreter.nodes.literals.BlockNode$BlockNodeWithContext.getOuterSelf(BlockNode.java:67)
> som.vmobjects.SBlock.getOuterSelf(SBlock.java:103)
> som.interpreter.nodes.ContextualNode.determineContext(ContextualNode.java:61)
> som.interpreter.nodes.NonLocalVariableNode$NonLocalVariableReadNode.doObject(NonLocalVariableNode.java:60)
> som.interpreter.nodes.NonLocalVariableNodeFactory$NonLocalVariableReadNodeFactory$NonLocalVariableReadObjectNode.executeGeneric(NonLocalVariableNodeFactory.java:513)
> som.interpreter.nodes.ExpressionNode.executeSObject(ExpressionNode.java:90)
> som.interpreter.nodes.FieldNode$FieldWriteNode.executeSelf(FieldNode.java:153)
> som.interpreter.nodes.FieldNode$FieldWriteNode.executeGeneric(FieldNode.java:145)
> som.interpreter.nodes.ArgumentInitializationNode.executeGeneric(ArgumentInitializationNode.java:24)
> som.interpreter.Invokable.execute(Invokable.java:33)
> com.oracle.graal.truffle.OptimizedCallTarget.callProxy(OptimizedCallTarget.java:186)
> com.oracle.graal.truffle.OptimizedCallTarget.callInlined(OptimizedCallTarget.java:234)
> com.oracle.graal.truffle.OptimizedDirectCallNode.callProxy(OptimizedDirectCallNode.java:63)
> com.oracle.graal.truffle.OptimizedDirectCallNode.call(OptimizedDirectCallNode.java:54)
> som.interpreter.nodes.specialized.AbstractIfMessageNode.doIfWithInlining(AbstractIfMessageNode.java:54)
> som.interpreter.nodes.specialized.IfTrueMessageNode.doIfTrueWithInlining(IfTrueMessageNode.java:21)
> som.interpreter.nodes.specialized.IfTrueMessageNodeFactory$IfTrueMessageBooleanSBlock0Node.executeGeneric(IfTrueMessageNodeFactory.java:275)
> som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:37)
> som.interpreter.nodes.ArgumentInitializationNode.executeGeneric(ArgumentInitializationNode.java:24)
> som.interpreter.Invokable.execute(Invokable.java:33)
> com.oracle.graal.truffle.OptimizedCallTarget.callProxy(OptimizedCallTarget.java:186)
> com.oracle.graal.truffle.OptimizedCallTarget.callRoot(OptimizedCallTarget.java:272)
>
> ContextualNode.determineContext get a SBlock from the frame.
> Then the code gets a node (a BlockNodeWithContext) from this SBlock.
> Which in turn accesses the frame (in BlockNodeWithContext.getOuterSelf).
> But at this point the location can not be evaluated to a constant
> because all this access chain is rooted at the SBlock that was
> extracted from the frame and is not a constant.
>
> My changes make more devirtualization happen during partial evaluation
> and thus more inlining happens during partial evaluation.
> The problem is that before the frame.getObject call was not inlined in
> FrameUtil.getObjectSafe but now it is because of this additional
> devirtualization.
>
> Currently the partial evaluator enforces that accesses to
> FrameWithoutBoxing are done with a constant slot.
>
> I solved the problem by adding a @SlowPath to
> BlockNodeWithContext.getOuterSelf but i'm not sure how much it's a
> hack versus a proper solution. I think here the issue is around:
> - accesses to materialized frames (if i understand your code
> correctly, you're trying to access values in outer frames)
> - enforcing constant-foldable accesses to FrameWithoutBoxing
> - reaching non-constant Truffle Nodes in truffle compilations (the
> BlockNodeWithContext inside SBlock)
>
> This last point especially seems to be at odds with the Truffle
> philosophy about Nodes: they should always be constant-foldable when
> they reach the partial evaluator.
> However even without that last issue, your specific problem would
> still arise because of the first 2 points.
>
> Maybe someone who has better knowledge of these things in Truffle can
> give you a more detailed answer.

I talked with Thomas and Andreas and the conclusion was that we should
relax the assertions around FrameWithoutBoxing or even
CompilerDirectives.unsafeGet/Put... in general, those should rather be
performance warnings than assertions.

The separate issue of the BlockNodeWithContext inside SBlock remains though.

>
> -Gilles
>
> On Tue, May 27, 2014 at 12:45 AM, Stefan Marr <java at stefan-marr.de> wrote:
>> Hi Gilles:
>>
>> On 24 May 2014, at 16:45, Stefan Marr <java at stefan-marr.de> wrote:
>>
>>> Adopting the latest version of Graal, I am having trouble with failing optimization passes because of “The location argument could not be resolved to a constant.”
>>
>> I think, my problem starts with one of your commits, most likely: http://hg.openjdk.java.net/graal/graal/rev/ef6b8d1898e6
>> Well, actually that one doesn’t yield a working VM for me.
>> But the last good commit is: http://hg.openjdk.java.net/graal/graal/rev/a9f969e65b61
>> Afterwards, I get the “The location argument could not be resolved to a constant” issues described below.
>> And http://hg.openjdk.java.net/graal/graal/rev/fa66540676ce is definitely broken.
>>
>> Thanks
>> Stefan
>>
>>>
>>> For all case I investigated so far, I get a stack trace like the following:
>>>
>>>       at com.oracle.graal.truffle.FrameWithoutBoxing.getObjectUnsafe(FrameWithoutBoxing.java:84)
>>>       at com.oracle.graal.truffle.FrameWithoutBoxing.getObject(FrameWithoutBoxing.java:68)
>>>       at com.oracle.truffle.api.frame.FrameUtil.getObjectSafe(FrameUtil.java:38)
>>>       at som.interpreter.nodes.literals.BlockNode$BlockNodeWithContext.getOuterSelf(BlockNode.java:67)
>>>       at som.vmobjects.SBlock.getOuterSelf(SBlock.java:103)
>>>       at som.interpreter.nodes.ContextualNode.determineContext(ContextualNode.java:61)
>>>
>>> Now, the location in question, i.e., the frame slot, is used like this [1]:
>>>
>>>    public Object getOuterSelf(final MaterializedFrame frame) {
>>>      return FrameUtil.getObjectSafe(frame, outerSelfSlot);
>>>    }
>>>
>>> And defined as `private final FrameSlot outerSelfSlot;`
>>>
>>> This reminds me of a change I did in March [2] based on Andreas’ comment [3].
>>> But, now this problem seems to be back, and since I didn’t change anything in my code, but just updated Graal, it looks like there might be either a regression or an old problem exposed.
>>> However, I don’t really see how I could get the frame slot ‘even more constant’ than what I have now.
>>> Perhaps, I am reading the stack trace wrong, or there is something else going on?
>>>
>>>
>>>
>>> To reproduce, the following should give an up-to-date TruffleSOM (note the recursive git submodule checkout, core-lib probably needs an update if you got an older copy):
>>>
>>> git clone --recursive https://github.com/SOM-st/TruffleSOM.git
>>> ant jar
>>> ant test
>>> ./graal.sh -cp Smalltalk Examples/Benchmarks/BenchmarkHarness.som TreeSort 100 0 100
>>>
>>> Thanks
>>> Stefan
>>>
>>> [1] https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/literals/BlockNode.java#L67
>>> [2] https://github.com/SOM-st/TruffleSOM/commit/c002b9be8bbed2ecf0c7a3fce93f9c108563e73e
>>> [3] http://markmail.org/message/ad7jd2ewopheqo2l
>>>
>>>
>>> --
>>> Stefan Marr
>>> INRIA Lille - Nord Europe
>>> http://stefan-marr.de/research/
>>>
>>>
>>>
>>
>> --
>> Stefan Marr
>> INRIA Lille - Nord Europe
>> http://stefan-marr.de/research/
>>
>>
>>