Correct me if I'm wrong, but it seems that the GC is unaware of any memory coming from an allocator (unless it's a GCAllocator, of course), so it won't scan it. If that's the case, that's bound to cause problems if T has indirections.
On Thu, Jun 18, 2015 at 11:32:05PM +0000, Andrei Alexandrescu wrote: > First pass illustrating the basic data layout: > > http://dpaste.dzfl.pl/0d4a589ad6f5 > > Code is obviously barebones but passes tests and works with allocators. > > Notes: > > * I managed to not store one allocator per node, but there's one > allocator per range. That's needed if we want "orphan ranges" to work, > i.e. ranges that survive the list they came from. This is a clasic > convenience vs. efficiency thing. > > * There's a refcount per node because any given node may belong to > multiple lists. > > * Refcounting is interesting because many nodes are only used by the > previous node. So destroying a list is... funny. Never saw or wrote code > like this previously. See nukeTransitively. > > All in all things seem convex. Please destroy appropriately. > > > Thanks, > > Andrei