On Mon, Mar 30, 2009 at 06:34:18PM -0400, Michael McCandless wrote:
> What is the vtable for vtable vtable? Itself?
This is going to get a bit "meta" -- prepare yourself. :)
The "vtable" member for VTable objects is &VTABLE.
So, all of the following are true:
OBJ.vtable == &VTABLE;
VARRAY.vtable == &VTABLE;
VTABLE.vtable == &VTABLE;
We need VTABLE because VTables are Lucy objects, and not just arrays of
function pointers. They have methods, and they also contain a couple very
important pieces of class data, e.g. obj_alloc_size which is sizeof(Obj) for
Obj, sizeof(VArray) for VArray, etc.
> >> Do VTables only store methods? Or can they store fields as well?
> >
> > You mean could they store class data? I suppose they could. Initializing
> > might get a little messy, and I'd want to make sure that we locked them down
> > and made them stateless before threading starts.
>
> I actually meant data fields on the object, but class data ("static"
> in Java) is also good.
Oh, I think I understand now. Each VTable object does have a few member vars:
obj_alloc_size, vt_alloc_size, etc.
> Hmm... Python's cyclic collector won't collect cycles involving
> classes that have __del__ since it can't guess a safe order to run the
> __del__ methods. (I know we're expecting people to just avoid making
> cycles, but still important to know).
That's a bummer. But I think we'd need __del__ no matter what, since we need
to trigger C-level destructors.
> you could probably simply use that host_obj
> field to hold low value ref counts (which are not valid pointers).
> Though that's scary-C-hack-territory :)
If we could guarantee that, say, 0x0 (NULL), 0x1, 0x2, and 0x3 could never
represent a pointer to a real host object for every single system that Lucy
might be compiled on, we could probably prevent a few unnecessary host object
creations that way -- more than 0x3 and we're at the point of diminishing
returns. And I think we can, because malloc() always returns word-aligned
pointers, which 0x1, 0x2, and 0x3 would not be for any 32-bit or 64-bit system
where NULL was 0x0.
So, this is almost certainly safe, but makes the library less maintainable
because the hack has to be explained.
I think we should do it.
If we're really paranoid, we can check the return value for To_Host() and
throw an exception if it's less than 4.
Marvin Humphrey
