thinking about proper implementation of tail calls

Florian Weimer fw at deneb.enyo.de
Sat Sep 1 08:26:37 PDT 2012


* Remi Forax:

>> I would be surprised if tail calls give more flexibility.  Usually
>> it's the opposite, the mini-interpreter wins in terms of flexibility:
>>
>>    <http://www.enyo.de/fw/notes/tail-calls.html>
>
> This trick can work with a lexer because usually you don't keep states
> between each recognized tokens, it's harder to use the same trick with
> a parser or an interpreter.

I think the Go lexer from which this is derived has quite a bit of
state (not just the input position).  The state is global, so it might
not apply in a scenario where you use tail calls combined with massive
concurrency, but I don't think that's the interesting case anyway.

>> The mini-interpreter turns direct calls into difficult-to-predict
>> indirect calls.  This could be a drawback.  But optimizing that is
>> probably not much more difficult than a general implementation of hard
>> tail calls.
>
> no, I don't think so because as you said direct calls are not hard to 
> predict.

Is implementing efficient hard tail calls on the JVM really *that*
easy?


More information about the mlvm-dev mailing list