Truffle Splitting Heuristics cause compilation to never stabilize

[Stefan Marr]

Hi:

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

Thanks
Stefan

> On 26 Jul 2017, at 21:49, Thomas Wuerthinger <thomas.wuerthinger at oracle.com> 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 stefan-marr.de> 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
http://stefan-marr.de/research/