On Wed, Apr 10, 2013 at 5:49 AM, Nick Wellnhofer <[email protected]> wrote: > I don't think this will work as expected. The SV heads in Perl are > fixed-size and allocated from a special "arena". If an SV head is freed, > it's chained in a free list and possibly reused later. Allocating an SV head > via Newx might work technically, but when reusing the SV head, memory beyond > the standard SV struct will be wasted. Also, an SV allocated this way will > not be destroyed during global destruction.
Thanks for the critique, you saved me some work... The opposite approach -- allocating memory ourselves which impersonates an SV head -- also looks like a dead end. I was hoping that some combination of READONLY and IMMORTAL would prevent Perl from freeing the SV head while still allowing DESTROY to run. But IMMORTAL isn't a flag (it's a closed set of 4 specific SVs), and in any case, Perl expects to be able to read/write the SV head after DESTROY runs -- which means we couldn't free that memory during DESTROY. There really doesn't seem to be a way to have Clownfish::Obj extend the SV type and create a single contiguous block of memory which functions polymorphically as both as a Clownfish::Obj and as a Perl SV. For the sake of argument, consider a brute-force alternative technique for rationalizing memory consumption: fill the SV object slot (self->ref.host_obj) during object allocation in `VTable_Make_Obj()`, rather than creating that SV object lazily when it's needed. Unfortunately, that's all but certain to degrade both speed and memory consumption in the common case. It sucks that we need two heap memory blocks for any object which is accessed from C-space and Perl-space. But I guess you could say that the current system has some effective optimizations. I still plan to try the technique of having Clownfish extend the base host type with our Python bindings. Hopefully the same approach will work with other host languages as well. Marvin Humphrey
