[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Avoiding string duplication
- From: Chris Smith <space.dandy@...>
- Date: Fri, 8 Nov 2019 10:01:40 +0000
> On 6 Nov 2019, at 19:05, Roberto Ierusalimschy <firstname.lastname@example.org> wrote:
> There are some problems for a copying collector in Lua:
> - Strings in a stack cannot be moved. (More specifically, strings
> in stack regions corresponding to C calls cannot be moved.)
> - Userdata already assume fixed pointers to their blocks of memory.
> - A copying collector works on top of raw memory, while Lua does
> GC on top of an allocation function.
> For all these reasons, it seems very unlikely that Lua will ever
> change to a copying collector. Maybe it is time to change the manual
> and make official this behavior?
I would certainly like to see this made official. However, it does raise some other interesting points and questions:
- Strings are immutable in Lua, but not in C. C code can directly modify a Lua string and those changes will be reflected in all identical Lua String objects. This is now defined behaviour due to the above, and is consistent with table behaviour and Userdata.
- Is there any real difference between Userdata and String objects? Are Strings simply Userdata whose content is cached and on which string functions can be called?
- Do we need both types? Would it be useful to be able to convert between Userdata and String objects? That is, to explicitly uncache/duplicate a String object or to mark Userdata as containing String data?
I’m not really sure that anything I’ve said amounts to much more than navel gazing, but I think there are some interesting possibilities.
Chris Smith <email@example.com>