incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: Reference counting inside a GC host (was "real time updates")
Date Tue, 31 Mar 2009 04:52:35 GMT
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

View raw message