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

[Stefan Marr]

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



-- 
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525