Hi,

In a virtual machine I'm working on, D's GC is provided as one of the GC implementations a program can run under. This works great so far, but I've run into a little "issue": Finalization. I need a way to get a callback whenever a piece of memory is destroyed. I was thinking I'd use rt_attachDisposeEvent as suggested by Vladimir Panteleev, but we recently switched runtime objects to be D structs rather than classes (because classes impose two machine words in the header, which is extremely wasteful when we also have our own header with three (!) machine words). rt_attachDisposeEvent seems to only work with full-fledged monitor-capable Object instances.

So, is there any other way to go about this for plain pieces of memory
allocated via GC.calloc()?

Regards,
Alex

On Thu, 16 Feb 2012 18:36:58 +0100, Alex <xtzgzorex at gmail.com> wrote:

> Hi,
>
> In a virtual machine I'm working on, D's GC is provided as one of the GC implementations a program can run under. This works great so far, but I've run into a little "issue": Finalization. I need a way to get a callback whenever a piece of memory is destroyed. I was thinking I'd use rt_attachDisposeEvent as suggested by Vladimir Panteleev, but we recently switched runtime objects to be D structs rather than classes (because classes impose two machine words in the header, which is extremely wasteful when we also have our own header with three (!) machine words). rt_attachDisposeEvent seems to only work with full-fledged monitor-capable Object instances.
>
> So, is there any other way to go about this for plain pieces of memory
> allocated via GC.calloc()?
>
> Regards,
> Alex
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

Not yet, but it is needed in the longer term, e.g. for runtime loading of
shared library.
It can be done relatively easy by storing heterogeneous entries in the
pooltable and handle
them during mark by type. You'd have to beef up the binary search in
findPool because it dereferences
every entry to read the memory range. That might work halfway with the few
pools we usually have but
if you add more entries it'll kill your cache.

Not currently.  Seems like it would be easy enough to add, though.

On Feb 16, 2012, at 9:36 AM, Alex wrote:

> Hi,
> 
> In a virtual machine I'm working on, D's GC is provided as one of the GC implementations a program can run under. This works great so far, but I've run into a little "issue": Finalization. I need a way to get a callback whenever a piece of memory is destroyed. I was thinking I'd use rt_attachDisposeEvent as suggested by Vladimir Panteleev, but we recently switched runtime objects to be D structs rather than classes (because classes impose two machine words in the header, which is extremely wasteful when we also have our own header with three (!) machine words). rt_attachDisposeEvent seems to only work with full-fledged monitor-capable Object instances.
> 
> So, is there any other way to go about this for plain pieces of memory
> allocated via GC.calloc()?
> 
> Regards,
> Alex
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime