Re: Resumable VM Patch (-- is it dead) / Coco / etc

[Vyacheslav Egorov <mraleph@...>]

Hi,

Thanks for your answer Mike.

Mike Pall wrote:
> This is easy if there's an analyzable shadow copy of it written
> in Lua. The primary function, written in C, assembler or
> pre-compiled Lua, provides adequate performance for the fallback
> case 
>   

I thought about such approach: it is simple, elegant but somehow error 
prone. One need to maintain coherence between C-function and shadow copy.
But Jikes highly benefits from the possibilty to optimize runtime 
procedures in the same context as the whole program, with your VM I hope 
Lua will be able to benefit from the same thing.

> (called by the interpreter or not inlined).
>   

I am highly interested how inline is implemented. There are to cases 
here: "upfunctions" inlining and global function inlining. Both require 
checks and mechanism to fallback into non-optimized native code or even 
bytecode. Lets consider some code snippet:

local f = m.f

local function g(...)
 f(...)
end

During execution, after the closure creation f can be inlined (so there 
is possibility that different closures will not share the same optimized 
function body). Still if someone assigns to f  then this inlining 
becomes incorrect and g needs to be deoptimized. So we need some kind of 
write barrier here. I thought about it sometime ago, but have not 
managed to invent an elegant implementation (only pointer comparison 
before inlined body, but this approach is not usable with moving GC). 
Also it is interesting how fallback can be implemented.

The global inlining raises even more questions, because closure 
environment can be modified. Also pointer check becomes more expensive.

I am interested both in theoretical and practical part of this, any 
links and hints will be highly appreciated.

Regards,
e.v.e