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

[Chris Seaton]

Did Andreas' answer give you everything you needed? I'll just specifically
answer your questions about Ruby:

I don't copy self into a frame slot - not sure why, it's just never
occurred to me to do that as it's not mutable. Also I can't think of a
situation where I'm doing any numerical computation with self except for
the core library methods which are implemented in Java. Perhaps I should
take a look at doing that so it gets specialised as you say.

Since self is never in a frame slot I get it directly from the arguments
array each time, as you say.

When a block is defined (when we execute a block literal) I store self in
the block object - RubyProc. When the block is called I call the CallTarget
with that stored self instead of whatever self currently is. In order
words, I never need to access outer self - the correct self is always just
self.

In some circumstances I call a block with another value for self (for some
metaprogramming stuff). I think your approach might make this hard.

Chris


On 27 May 2014 21:27, Stefan Marr <java at stefan-marr.de> wrote:

> Hi Gilles,
> Hi Chris:
>
> On 27 May 2014, at 16:05, Gilles Duboscq <duboscq at ssw.jku.at> wrote:
>
> > The separate issue of the BlockNodeWithContext inside SBlock remains
> though.
>
> Gilles, thanks for having a look. That helps a lot. Now I have an idea in
> which direction to look.
>
> And that brings me to my next question, Chris:
>
> In BlockNodeWithContext, I access the outer ‘self’ slot, which I need to
> traverse the chain of lexical contexts.
> In TruffleSOM, all arguments of method calls are directly copied into the
> frame objects to enable specialization via FrameSlots (see
> ArgumentInitializationNode and its usage). After that, I never access the
> arguments array anymore.
>
> To get access to the self slot in that design, I keep a reference to the
> corresponding node in the block object.
> Previously, I had the reference directly to the frame slot object, but
> that gave already issues because then it was not constant.
> Guess, changing the reference to the node was just hiding the problem,
> without solving it.
>
> Chris, a brief look at the Ruby implementation makes me belief that you do
> not do that for accessing the lexical chain.
> You are using the arguments array directly via
> RubyArguments.getDeclarationFrame(). Is that to avoid exactly the issue I
> got here?
>
> At the moment, I guess that’s the only solution that avoids the need of
> having access to the frame slot object.
>
> Thanks
> Stefan
>
>
> --
> Stefan Marr
> INRIA Lille - Nord Europe
> http://stefan-marr.de/research/
>
>
>
>