malloc in core.memory.GC

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


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.

-- 
- Alex


More information about the Digitalmars-d mailing list