Truffle Splitting Heuristics cause compilation to never stabilize

Stefan Marr java at
Tue Nov 14 16:28:30 UTC 2017


Any updates on this issue?
It seems to come back biting us. Now it seems the culprit in some fork/join workloads.


> On 26 Jul 2017, at 21:49, Thomas Wuerthinger <thomas.wuerthinger at> wrote:
> Thanks Stefan. This is a great catch! We need to fix the splitting heuristics to cover indirect recursion. - thomas
>> On 26 Jul 2017, at 17:57, Stefan Marr <java at> wrote:
>> Hi:
>> I have been running into a stabilizing issue with a small benchmark from the Newspeak benchmark suite.
>> The issue exists however also in other languages.
>> Let’s take Ruby as example, which might be more legible:
>> def fib(x)
>> -> n {
>>   if n < 2
>>     1
>>   else
>>     fib(n-1) + fib(n-2)
>>   end
>> }.call(x)
>> end
>> loop { fib(25) }
>> The main problem here is that we have an indirectly recursive function, which itself has only a single call.
>> This means, DefaultTruffleSplittingStrategy will see fib and say hey isMaxSingleCall==true, let’s split it.
>> In the block itself, fib is then split again and again, because it is not directly recursive, but one indirection removed. So, the recursion heuristic doesn’t trigger.
>> In my Newspeak (SOMns), the problem is further exaggerated because when a method gets split, I also split its embedded blocks to allow type specialization of local variables. This isn’t the case in TruffleRuby however.
>> Is there anything that could be done to make DefaultTruffleSplittingStrategy a little smarter about this?

Stefan Marr
School of Computing, University of Kent

More information about the graal-dev mailing list