April 09, 2012
On 09-04-2012 16:16, Steven Schveighoffer wrote:
> On Sun, 08 Apr 2012 16:33:01 -0400, Alex Rønne Petersen
> <xtzgzorex@gmail.com> wrote:
>
>> APPENDABLE is, IIRC, mostly an internal attribute used for the array
>> append cache. You can ignore it entirely (we should document this).
>
> It's used to flag that the block of GC data is actually an appendable
> array. If this flag is missing, and you attempt to append data that
> points at the block, it will always reallocate. If this flag is present,
> it assumes it has a valid the "used" length in the block, and proceed.
> Do NOT set this flag unless you know what you are doing. Let the runtime
> do it.
>
>> FINALIZE is only relevant if the type allocated in the block has a
>> destructor (it simply specifies that finalization is then desired).
>
> I'll add that it not only identifies the type stored has a dtor, the GC
> expects that the layout of the block is of type Object. This is an
> important distinction, because it will use that information to traverse
> the vtable looking for dtors. For example, just setting this flag for a
> struct that has a dtor will not work, because a struct has no vtable.

Something that I've always disliked about the current GC.

In MCI, I can't provide finalization support when programs running in the VM use the D GC, because that *requires* me to use the Object layout for runtime objects. That's just not nice, since it adds (IIRC) 3 words of data that's basically useless to *me*. It would be nice if the GC supported finalization callbacks similar to how Boehm does it.

>
> -Steve


-- 
- Alex
April 09, 2012
On Mon, 09 Apr 2012 13:39:10 -0400, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:

> In MCI, I can't provide finalization support when programs running in the VM use the D GC, because that *requires* me to use the Object layout for runtime objects. That's just not nice, since it adds (IIRC) 3 words of data that's basically useless to *me*. It would be nice if the GC supported finalization callbacks similar to how Boehm does it.

Well, considering that there is no reason whatsoever to expect anything stored in the block except the exact object it was created with, I see no reason why you couldn't store a TypeInfo reference in the block somewhere (not part of the object/struct).

This would mean you could determine the type without having the type system, and it would mean you would not carry around the extra baggage for calling the finalizer from the GC, when the struct is stored on the stack.

I had great success with this when fixing array appending, I don't see why it couldn't be done with finalization.  We do need compiler support to make sure the struct dtor function pointer gets stored in the TypeInfo, not sure if this has already been done.

-Steve
1 2
Next ›   Last »