Re: Userdata environment example (Re: GC method for objects)

[Mark Hamburg <mhamburg@...>]

on 4/24/05 6:09 AM, Mike Pall at mikelu-0504@mike.de wrote:

> Some very simple userdata objects may have no use for the userdata
> environment. Yes, this wastes a little bit of space. Here are the
> old and the new sizes of the constant portion of userdata objects:
> 32 bit CPUs: 16 -> 20 bytes, 64 bit CPUs: 32 -> 40 bytes
> (this may or may not make a difference, depending on your malloc()
> implementation). But I think the advantages outweigh this disadvantage.

I full well recognize the benefits of this. I was an advocate quite a while
ago of upvalues for userdata and this solves it more neatly. The weak table
solution is just a mess from a tracing standpoint.

I will say on your 32-bit CPU case that what one is probably looking at is a
growth from 16 to 24 bytes due to double-alignment issues. Unaligned doubles
can be very, very bad on some processors. This is sad since many userdata
objects actually only contain a pointer and those don't need the alignment.

Returning to the issue of function environments, is there a reason to
preserve support for upvalues for C functions given environment tables? I'm
not necessarily advocating their removal, but it seems like the environments
mechanism may have significantly diminished their value.

(Going the other direction, I had thought once about trying to implement
light C functions that would be akin to light userdata. I should try to find
time to go do that. Doing so would, for example, make cpcall a bit faster
and would avoid the danger in the RVM implementation of a memory allocation
failure while trying to push the function.)

Mark