malloc in core.memory.GC
Alex Rønne Petersen
xtzgzorex at gmail.com
Mon Apr 9 10:39:10 PDT 2012
On 09-04-2012 16:16, Steven Schveighoffer wrote:
> On Sun, 08 Apr 2012 16:33:01 -0400, Alex Rønne Petersen
> <xtzgzorex at 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
More information about the Digitalmars-d
mailing list