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

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

Hi,

Mark Hamburg wrote:
> 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.

You are right. I just tried it on a PPC 32 bit cpu and there the
new size is 24 bytes (oh well). I forgot about the union with
L_Umaxalign (see lobject.h, union Udata).

As far as x86 is concerned: userdata is only a small part of the
problem with misaligned doubles. The Lua stack is made out of 12 byte
TValue pairs and every other element may potentially contain an
unaligned double. Dito for both the array part and the hash part
of tables (I guess your patch for reorganizing the internal table
fields to save space addresses that, too).

At least on my system (PIII) the unaligned access to doubles seems
to be not much of a penalty. I once tried to add a dummy field to
TValue to make it 16 bytes, but the higher memory bandwidth outweighed
the benefit of aligned access to doubles. Anyone worried about this
should try this with an application specific benchmark and on different
CPUs, though.

> 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.

I do use multiple upvalues. Removing this feature would be rather
inconvenient (and slower, too). There is no space penalty since
upvalues are allocated at the end of the closure object. Removing
C function upvalues would save only very little code in the Lua core
(e.g. because Lua functions still need upvalues). There is not much
to be gained.

Put another way: now Lua functions and C functions both have an
environment and both have upvalues. This increases orthogonality,
which is a good thing (most of the time).

[Umm ... I just noticed a restriction in lua_setfenv() that the
environment must be a table and cannot be any arbitrary Lua object.
While this makes sense for Lua functions, it removes some flexibility
for C functions and userdata objects. Maybe this was done for
consistency? Roberto?]

> (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.)

Well, I thought cpcall would be used only once during initialization
(and there the semantic differences wrt memory allocation would not
make much of a difference). But this sounds like you're using cpcall
very often? Care to elaborate?

[Because otherwise I fail to see the necessity for a LIGHTFUNCTION
 type, considering that you'll have to mess with lots of code
 in the core and elsewhere. There is additional trouble ahead because
 type(func) may then return two things and any conditionals based
 on this will need to be revisited.]

Anyway, if it's important for you I can easily restore the old
semantics of cpcall in the next issue of the RVM patch (against
the next standard 5.1 work version). It's around 20 lines of code.

Bye,
     Mike