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