malloc in core.memory.GC

Alex Rønne Petersen xtzgzorex at gmail.com
Sun Apr 8 13:34:45 PDT 2012


On 08-04-2012 22:33, Alex Rønne Petersen wrote:
> On 08-04-2012 22:05, Andrei Alexandrescu wrote:
>> At http://dlang.org/phobos/core_memory.html, the spec for GC.malloc is
>>
>> static void* malloc(size_t sz, uint ba = 0);
>>
>> I assume each type has a specific ba. Is there a primitive in
>> core.memory to retrieve it?
>>
>>
>> Thanks,
>>
>> Andrei
>
> Currently, no. I think (but don't quote me on this) that there is some
> compiler magic involved. That, or it's hidden somewhere deep inside rt.*
> (probably rt.lifetime).
>
> FWIW:
>
> NO_SCAN is set for types that have no GC-relevant pointers (i.e. it's
> pure data; integers, floats, etc). We ought to document under what exact
> circumstances a type has this flag...
>
> APPENDABLE is, IIRC, mostly an internal attribute used for the array
> append cache. You can ignore it entirely (we should document this).
>
> NO_INTERIOR can probably be ignored for most practical purposes as it's
> an optional optimization. It won't be used unless you explicitly tell
> the GC to do so.
>
> FINALIZE is only relevant if the type allocated in the block has a
> destructor (it simply specifies that finalization is then desired).
>
> NO_MOVE isn't currently used for anything since the GC doesn't do any
> copying/compaction (in general). Even when the GC does get such
> semantics, this probably falls into the same ballpark as NO_INTERIOR
> (i.e. a library shouldn't mess with this).
>
> You can test any of the above flags by creating types fulfilling the
> criterion and querying the GC for their memory block's attributes.
>
> TL;DR: Only NO_SCAN and FINALIZE are interesting if this is for your
> allocators design.
>

I should add that both NO_INTERIOR and NO_MOVE should *not* be generally 
used at all by a library or similar. They require careful consideration 
and defensive programming by the programmer.

-- 
- Alex


More information about the Digitalmars-d mailing list