Initializing Truffle frames | Was: How to do AST inlining of method calls?

[Andreas Woess]

The problem is probably what VerifyFrameDoesNotEscapePhase 49-53 says:
the FrameSlot parameter is not a compile-time constant. While that
assertion might be overly restrictive here since you actually do
materialize it, that doesn't change the fact that one shouldn't access
virtual frames with a non-constant FrameSlot parameter.

Looks like the problem here is that the contents of the argumentSlots
and temporarySlots array aren't constant-folded (yet). Worry not, we
have changes in the pipeline that will probably fix this without
changing your code. You should remove the materialize() then.

- andreas

On 11.09.2013 16:33, Stefan Marr wrote:
> Hi Andreas:
>
> On 11 Sep 2013, at 02:31, Andreas Woess <andreas.woess at jku.at> wrote:
>
>> I also wonder why you immediately materialize the frame for initializeFrame; this shouldn't be necessary.
> I am not sure, but I think Thomas suggested that originally.
> Now, looking at it and trying to understand VerifyFrameDoesNotEscapePhase line 49-53, I think the reason for using a materialized frame is that I need to initialize the frame object with arguments.
> The relevant code is [1]:
> So, each frame contains self, a marker object that tells me whether the frame is still alive/available, the method's arguments and temporary fields required during execution of the method. These need to be all initialized based on the arguments object.
>
>   @ExplodeLoop
>   private FrameOnStackMarker initializeFrame(MaterializedFrame frame) {
>     Object[] args = frame.getArguments(Arguments.class).arguments;
>     try {
>       for (int i = 0; i < argumentSlots.length; i++) {
>         frame.setObject(argumentSlots[i], args[i]);
>       }
>
>       frame.setObject(selfSlot, frame.getArguments(Arguments.class).self);
>
>       FrameOnStackMarker marker = new FrameOnStackMarker();
>       frame.setObject(nonLocalReturnMarker, marker);
>
>       for (int i = 0; i < temporarySlots.length; i++) {
>         frame.setObject(temporarySlots[i], universe.nilObject);
>       }
>
>       return marker;
>     } catch (FrameSlotTypeException e) {
>      throw new RuntimeException("Should not happen, since we only have one type currently!");
>     }
>   }
>
> I think, I remember that Thomas suggested to change this approach in order to allow for specialization based on number of arguments and temporaries, I suppose.
> Am not entirely sure thought.
> Also, I don't see how that would lead the arguments and self to be compile time constants, which is what I understand is what VerifyFrameDoesNotEscapePhase is checking for in the second part.
>
>> Regarding your last email, you might want to consider rewriting control
>> structures / well-known messages like ifTrue, whileTrue, etc. to
>> specialized nodes instead of going through a normal call, e.g. a
>> WhileTrueNode with inlined condition and block.
> I would like to avoid that for the moment.
> Once I get the inlining working, I would rather like to experiment with getting rid of boxing integers :)
>
> Thanks
> Stefan
>
> [1] https://github.com/smarr/TruffleSOM/blob/master/src/som/interpreter/nodes/Method.java#L89
>
>
>