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

Tue May 27 13:48:48 UTC 2014

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.

-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/
>
>
>