JVMLS indy support group provisional agenda

Jochen Theodorou blackdrag at gmx.org
Mon Aug 1 08:41:27 UTC 2016


On 01.08.2016 08:37, Vladimir Ivanov wrote:
>> And let's not forget:
>> - coroutine
>> - tail call
>
> How do they relate to "Indy Support Group" (as recorded in JVMLS
> agenda)? :-)

both of them most likely will need a special kind of method call. And 
both could be implemented using a trampoline like base

For example if you had the ability to make a call and jump put of the 
current stack frame at the same time you could implement tail calls to 
some extend. A simple implementation I used in the past requires a 
method that calls a tailcall enabled method to use a special call 
instruction... something like this:

callcc foo(0)

def foo(i) {
   returncc bar(i+1)
}

def bar(j) {
   returncc foo(j+1)
}

returncc records the method call, but returns to callcc, which does the 
actual execution of the call. Now imagine callcc and returncc being 
invokedynamic functions, where returncc can return to the frame of 
callcc and the callcc handle executes the handle produced by returncc.

My implementation I tried out in the past was actually using a special 
return type and a loop in the implementation of callcc, which I found 
questionable performance wise and too intrusive type-wise.

An idea for a coroutine would be to again have a similar "exit frame 
with state", but this time instead of directly using that in the caller 
code, to save the state in an object and to use that to get back and 
continue with later on. The coroutine itself would have to be unrolled 
to some extend, to allow jumping to a certain position in the bytecode 
by restoring state from the coroutine object. Of course having your own 
substack would be even better, but well...

But I guess such techniques are nothing new to anyone reading here ;) 
Anyway... invokedynamic could help hiding implementation details here a 
lot, and the ability to exit the current stack frame with user defined 
state beyond a simple return would be really really interesting for 
those implementations.

bye Jochen


More information about the mlvm-dev mailing list