Truffle Splitting Heuristics cause compilation to never stabilize

Christian Humer christian.humer at
Tue Nov 14 17:05:09 UTC 2017

Hi Stefan,

No not yet. We are working on a general overhaul of the splitting 
But this should probably be fixed independently of that. We will work on 
a fix for this ASAP.
We will reply here as soon as its done.



On 14.11.2017 17:28:30, "Stefan Marr" <java at> wrote:

>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:
>>>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
>>>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