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

[Mike Pall <mikelu-0708@...>]

Hi,

Thomas Harning Jr. wrote:
> Just wondering, is the resumable VM patch in use/development?

Greg Falcon has taken over maintenance and upgraded RVM to work
with Lua 5.1 final. The functionality is quite complete, so
there's not much left to do. Are you missing anything?

> I find it much more palpable than using Coco and limiting my # of
> coroutines or having to guess how much stack I need.  Limiting my # of
> coroutines because 32k of stack per coroutine (looks like thats it
> from the src code) is quite a bit.... even if it is lower than that,
> then I have to guess how much stack is going to be needed.

Sure, stack sizing is a potential problem with Coco. But it seems
to be a non-issue in practice, unless you aim for many thousands
of coroutines. But note that you can selectively assign a C stack
to some coroutines and not to others (read the Coco docs for
coroutine.create).

It really depends on what part of the functionality you need:
1. yield across pcall.
2. yield across metamethods, iterators, callbacks.
3. yield from C calls and resume back to them.

For intensive coroutine use, you can sometimes redesign your code
and let coroutine.resume catch all exceptions (solving item 1).
Items 2 and 3 require you to go through some hoops with RVM,
whereas Coco makes this really easy. The portability issues with
Coco are overrated -- it runs on almost any system you'll ever
encounter.

Both Coco and RVM are valid solutions, there's no clear winner.

> Anybody find any useful solutions/benchmarks/usage scenarios...

Sure, I'd like to hear about that, too. So, what's your usage
scenario?

> Another direction... does anybody see mixing an RVM w/ LuaJIT/Coco
> possible in the future?
> Perhaps you'd have to tag a coroutine as being resumable using RVM or Coco...

RVM was not really feasible for LuaJIT. This was the major reason
why I wrote Coco. IMHO mixing RVM and Coco is way too complex.

[
The LuaJIT 2.x VM I'm working on right now is rewritten from the
ground up. It's a very, very different design. Most library
functions (including pcall and yield) aren't C functions anymore.
The explicit Lua call stack is gone. C stacks are allocated
on-demand and recycled.

If all coroutines yield only from C code (and stay suspended), it
degenerates to the Coco behaviour. But most use cases behave more
like RVM and consume very little memory.

Nope, sorry, no ETA for a release anytime soon. :-)
]

> Speaking of patches.. has there been any more discussion re the atomic
> small-strings patch?

You mean my "Fast String Patch" from 2005? Well, it was an
interesting experiment. But it suffers from problems with the
Lua/C API. And it doesn't seem to pay off enough to warrant the
additional complexity of handling two different string types
throughout the whole VM.

A compiler may be able to achieve similar effects with escape
analysis. The trade-offs are different than in an interpreter.
E.g. one doesn't need two string types. It's sufficient to pass
around pointer/length pairs in contained code fragments.

Bye,
     Mike