On Friday, 1 November 2013 at 02:43:00 UTC, Andrei Alexandrescu
wrote:
On 10/31/13 7:26 PM, safety0ff wrote:
I noticed that the GCAllocator provides no way of controlling
the memory
block attributes
(http://dlang.org/phobos/core_memory.html#.GC.BlkAttr
,) all allocations get the default (no attributes.) This is a
leaky
abstraction, a data structure or composed allocators may
desire to
control the attributes to reduce GC pressure.
These attributes seem to be informed by the types stored, which
would be above the charter of untyped allocator.
Andrei
The attributes are informed by whatever code is calling the GC,
the GC interface deals in void*'s.
Consider an AA implementation that wishes to use FancyAllocator
with fallback GCAllocator with block attributes NO_INTERIOR and
NO_SCAN.
With your proposed GCAllocator you either need to rewrite
GCAllocator, or you need to add some nasty code to set the
attributes depending on whether the primary allocator or
secondary allocator own the memory.
By fixing the leaky abstraction this use case can be coded as
follows:
FallbackAllocator!(FancyAllocator,
GCAllocator!(GC.BLkAttr.NO_INTERIOR | GC.BLkAttr.NO_SCAN)) a;
