Re: [PATCH] make light userdata a little bit heavier

[Ross Bencina <rossb-lists@...>]

On 22/04/2014 6:54 PM, Tom N Harris wrote:
> The other alternative, which has a similar cost to a weak table, is to use
> full userdata.

Unless I'm missing something (quite possibly I am), a trip to the 
allocator for each new full userdata value is not really "similar cost" 
to a light userdata.

Compared to full user data the weak table seems like a good approach. Do 
you see a way to automatically purge stale values?


> The Peng proposal discarded this based on the assumption that
> each unique pointer type would need its own metatable. That doesn't have to be
> the case. A single metatable can be used for all managed pointers if the
> userdata boxes the pointer and the type.
>
>      typedef struct { void * p; int t; } typedpointer;
>      if ((typedpointer)lua_touserdata(L, 1)->t == TYPE) {}


Does it work if you are passed a user data created by some other piece 
of code that doesn't know about this boxing? Seems to me that it suffers 
from the same problem that we're trying to solve. (p->t == TYPE) breaks 
if the userdata is not one that you created.

The way that I understand it, we need to set a metatable on userdata to 
get the required safety.


> Summary of my argument: how can you say full userdata is wasteful, then
> propose to increase the size of every value?

Two answers:

1. I'm with you. I much prefer the "use spare bits that are already 
there" patch than the "increase size of every value" patch.

2. Full user data incurs allocator and GC overhead. Intuition tells me 
this is going to cost more than adding an extra few bytes to every 
value, at least up to the point that the data set doesn't fit in the 
cache. Then the pendulum might swing the other way. On resource 
constrained systems the situation might be different.

I'm pretty confident that a patch that increases the size of all values 
for some relatively obscure benefit would never make it into core. So 
I'm more interested in the non-value-increasing options, and in 
supporting the availability of such a feature (and discovering ways to 
do it without he patch).

Ross.