Re: caching pointers to Lua strings?

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

Peter Cawley wrote:
> I interpret the manual to mean that should a Lua implementation use a
> moving GC, it is only required to fix the address of strings while
> they live on the stack, and is free to move them around once they are
> off the stack.

That's my interpretation, too. The wording carefully leaves open
the door for a future moving GC, though none of the current
implementations (*) make use of it.

[
Since I pondered over implementing a moving GC, I've come to the
conclusion that this guarantee does not lead itself to a practical
implementation, though. It would be quite complicated and/or
expensive to track the pinned strings. And unpinning is implicit.

An explicit API for pinning/unpinning strings would help a lot.
Most uses of strings in the C API don't need to be pinned and
wouldn't need to pay for the overhead. Pinning a string might move
it to a special pool, increment a reference counter and return it.
Unpinning would decrement the reference counter and (lazily) move
it to the regular pool. There are other implementation choices, of
course. But being explicit about your intentions always helps.
]

(*) Note that the JVM/CLR translations of Lua don't come with a
compatible Lua/C API. So they don't have to deal with that issue,
even though the underlying virtual machines use a moving GC.

--Mike