[Truffle] Loop count propagation
Stefan Marr
java at stefan-marr.de
Thu May 29 15:07:37 UTC 2014
Hi Chris:
On 29 May 2014, at 16:42, Chris Seaton <chris.seaton at oracle.com> wrote:
> Might you have some strange interactions if a block is defined in one method, then stored somewhere and called from somewhere else?
Good question. I think, none of the benchmarks I have do that. So, I probably won’t optimize for that.
However, another interesting scenario is to pass a block/lambda to some method, which then uses it repeatedly.
This seems to be pretty often the case in Smalltalk, with internal iteration etc.
I guess, it could help to propagate the call count of blocks to their outer method in those cases, to increase the chances that the outer method gets compiled, and access to materialized frames gets compiled away. Or to make sure they get compiled as early as possible.
> 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?
In your example, I am not sure why bar would need to be compiled. As long as x is properly compiled.
In SOM, I would however worry that x, i.e. your lambda uses a materialize frame. And, since I always capture self, and I think I almost always need it, for error reporting, I am not sure I can be smart in the compiler here to avoid creating a materialized frame.
> 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?
When a method is split for inlining, all lexical enclosed blocks are split as well. You need that to enable them to specialize their frame access in the new method. And, in the same way, they all get their proper lexical context.
[That is done by Inliner [1], and replaceWithIndependentCopyForInlining(.)].
>> 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.
I guess, it might also depend on which kind of usages are most common for lambdas. So, don’t know which approach is preferable. It is probably also language-dependent.
Best regards
Stefan
--
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/
More information about the graal-dev
mailing list