On Tue, Mar 31, 2009 at 12:52 AM, Marvin Humphrey
<[email protected]> wrote:
> 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;
OK so VTABLE's vtable is simply itself.
> 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.
Got it.
>> >> 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.
Actually I meant eg SegMetaData (not sure on the name) would have a
String data memeber segmentName in it. Is there an entry in VTable
for members that are data, not methods?
>> 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.
Yeah. The whole "finalizers cannot be run in a deterministic manner
so we simply don't collect class with finalizers" things is scary...
all tracing collectors struggle with this.
>> 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.
Nice! The scary things you can do in C...
Mike
