On 10/31/13 8:37 PM, safety0ff wrote:
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;
Migrating the flags into the type is a possibility but maybe it's
easiest to add flags as runtime parameters.
Allocators can always define additional nonstandard routines. The
standard routines concern mostly composition.
Of course, it is also possible to make such flags standard (it may be
the case that typed allocators require such).
Andrei
