Re: Feature request: userdata slice

[William Ahern <william@...>]

On Thu, Aug 20, 2015 at 07:05:22PM -0300, Roberto Ierusalimschy wrote:
> Maybe I am missing something, but if we want to put some extra bits in
> 'TValue' to good use and solve the OP problem, maybe a better idea would
> be to introduce metatables for light userdata.
> 
> There would be a limit on the number of different metatables that light
> userdata can have, but it would be a reasonable high limit [2^25] for
> typical uses of metatables. If we adopt this limit for all metatables in
> the system, we could gain some space in tables and full userdata, too.
> (We could even gain individual metatables for numbers :-)
> 

Yes, that sounds like a genius idea! It took me awhile to think through all
the implications. IIUC, the OP could just generate a single unique metatable
for each full userdata object he wants to clone. He stores a reference to
the full userdata object in the metatable; the lightuserdata value becomes
the index into the full userdata (or some other object it references).

The metatable reference, stored in the unused bits of the type tag, indexes
an array of pointers to Table objects, right? For 64-bit systems where there
are fewer significant bits in pointers (e.g. only 48 bits on AMD64 and
AArch64) the indirection penalty could be avoided by using a uintptr_t for
the type tag. That would increase the size of TKey, but it could be
recovered by reordering Node using the same tricks used to pack TKey. AFAICT
on 64-bit machines Node still wastes 32 bits.

FWIW, I realized after I my previous post that the OP could maintain a cache
of full userdata for generating ephemeral document references. He could
resurrect the userdata objects from the __gc handler and place them back
into a queue. That would significantly reduce the number of allocations and
deallocations, although maybe that's not as much of a problem as the amount
of marking & sweeping the GC performs.