> >> > I'd really like to kill of FastObj just for the sake of simplicity,
> >> > though.
> >>
> >> What objects are planned to subclass FastObj?
> >
> > VTable, plus the CharBuf family.
> >
> > Right now in KS, the following classes also descend from FastObj:
> >
> > VArray
> > Posting
> > Token
> > Inversion (nee TokenBatch)
> > ByteBuf
> > ViewByteBuf
> > Undefined
> >
> > However, none of them have the declaration/bootstrapping problem presented
> > by
> > VTable and CharBuf.
I think I have an approach that's going to allow us to eliminate FastObj: We
lazily create the host object, and treat a NULL host_obj as semantically
equivalent to a refcount of 1.
chy_u32_t
lucy_Obj_dec_refcount(lucy_Obj *self)
{
if (self->ref.host_obj) {
chy_u32_t modified_refcount = SvREFCNT((SV*)self->ref.host_obj) - 1;
/* If the SV's refcount falls to 0, DESTROY will be invoked from
* Perl-space.
*/
SvREFCNT_dec((SV*)self->ref.host_obj);
return modified_refcount;
}
else {
/* NULL host_obj implies a refcount of 1, so invoke Destroy(). */
Lucy_Obj_Destroy(self);
return 0;
}
}
That allows us to declare VTable and CharBuf structs at compile time, by
inserting NULL where the host object would be.
I've switched oer VTable and CharBuf with either zero or maybe 1% impact on
performance (the numbers are noisy).
The only thing that's weird is that I can't figure out what's happening to the
Perl objects these persistent objects must be acquiring. I think they're
getting zapped during Perl's "everyone out of the pool" global destruction
phase, but I'm not sure yet -- I tried to make VTables leak by incrementing the
refcount a while bunch of times in the VTable_singleton() constructor, but
couldn't get Valgrind to show anything.
Marvin Humphrey
