[Truffle] Loop count propagation

Chris Seaton chris.seaton at oracle.com
Thu May 29 14:42:32 UTC 2014


> On 28 May 2014, at 15:41, Chris Seaton <chris.seaton at oracle.com> wrote:
> 
>> On 28 May 2014, at 14:21, Stefan Marr <java at stefan-marr.de> wrote:
>>> Pass loop counts up to the first call target for a method that is not a block.
>>> https://github.com/jruby/jruby/commit/74934f06299f896170e37cd538c594f6dd27fb35
>> 
>> This change greatly improved warmup time and generated fewer compiled methods. I’ll illustrate using JavaScript, to avoid any confusion about Ruby or SmallTalk syntax and to make it more accessible to other people reading this:
> 
> This indeed has a good impact on warmup time for TruffleSOM as well. For DeltaBlue, warmup time was halved, I think. For the rest it might be even better.
> https://github.com/SOM-st/TruffleSOM/commit/e1a47e453f8d4e0db06d03f788d74fbe24763743
> 
> Just one more question, does the dynamic traversal of the stack in your solution in `reportLoopCountThroughBlocks()` give you additional benefits? I didn’t do it that way, but instead used only the static lexical context.

Doing it lexically is a very interesting idea.

Might you have some strange interactions if a block is defined in one method, then stored somewhere and called from somewhere else? Would it help the method it was lexically defined in be compiled, when it might be being used by some unrelated method? Using JS again:

function foo() {
  return function() {
    ...
  }
}

x = foo()

function bar() {
  loop(x)
}

bar()

Will that cause foo to be compiled, when we’d rather bar was?

Also, if your method is an invokable, which is a root node, what happens when a root node is cloned for splitting and inlining? Does that leave methods referring to the old copy of the method in their LexicalContext?

I did it dynamically because what inspired me to do it was the new stack trace API, which suddenly have my access to the stack of call nodes.

> Also, depending on how the block is used, if there is any kind of helper method in-between on your stack, the loop count won’t reach the outer method, I think.

Yes, that’s true. Not sure what to do about that.

Chris


More information about the graal-dev mailing list