Re: Resumable VM Patch (-- is it dead) / Coco / etc
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Resumable VM Patch (-- is it dead) / Coco / etc
- From: Vyacheslav Egorov <mraleph@...>
- Date: 2007年8月23日 09:35:34 +0700
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