Tracing API?

[Joseph Rushton Wakeling]

On 16/12/13 05:15, Andrei Alexandrescu wrote:
> Seems like the low-level allocator is faring quite well. After quite a bit of
> thinking on the higher-level allocator, it seems to me I could attack the entire
> tracing/GC matter heads-on, possibly ultimately complementing or even providing
> an alternative (or more!) for the existing GC. The fresh modular approach
> focused on composition could make it much easier to design and implement
> high-performance collectors.

GC- and allocator-related question, a bit tangential to the current discussion, 
but humour me please, it's related to some ongoing Phobos-related work which 
I'll be sharing shortly :-)

Suppose that I have a class -- which would normally be allocated on the heap.

Now consider a couple of scenarios:

     (i) I want to allocate it on the stack, not the heap, but have it otherwise
         behave like a normal class, and be garbage-collected.  Feasible, via
         this allocator framework or otherwise?

    (ii) I want to allocate it without invoking GC (either on stack or heap).
         How would this affect the use of methods like .save or .dup which
         involve allocating a new instance?

If this is too vague, no worries -- I'll revisit the questions in the context of 
the particular code I'm working on -- but I thought I might as well ask, since 
allocation strategies are being discussed :-)

Thanks & best wishes,

     -- Joe