Memory management design

[sclytrack]

On Tuesday, 9 July 2013 at 23:32:13 UTC, BLM768 wrote:
> Given all of this talk about memory management, it would seem 
> that it's time for people to start putting forward some ideas 
> for improved memory management designs. I've got an idea or two 
> of my own, but I'd like to discuss my ideas before I draft a 
> DIP so I can try to get everything fleshed out and polished.
>
> Anyway the core idea behind my design is that object lifetimes 
> tend to be managed in one of three ways:
>
> 1. Tied to a stack frame
> 2. Tied to an "owner" object
> 3. Not tied to any one object (managed by the GC)
>
> To distinguish between these types of objects, one could use a 
> set of three storage classes:
>
> 1. "scope": refers to stack-allocated memory (which seems to be 
> the original design behind "scope"). "scope" references may not 
> be stashed anywhere where they might become invalid. Since this 
> is the "safest" type of reference, any object may be passed by 
> "scope ref".
>
> 2. "owned": refers to an object that is heap-allocated but 
> manually managed by another object or by a stack frame. "owned" 
> references may only be stashed in other "owned" references. Any 
> non-scope object may be passed by "owned ref". This storage 
> class might not be usable in @safe code without further 
> restrictions.
>
> 3. GC-managed: the default storage class. Fairly 
> self-explanatory. GC-managed references may not refer to 
> "scope" or "owned" objects.
>
> Besides helping with the memory management issue, this design 
> could also help tame the hairy mess of "auto ref"; "scope ref" 
> can safely take any stack-allocated object, including 
> temporaries, so a function could have "scope auto ref" 
> parameters without needing to be a template function and with 
> greater safety than "auto ref" currently provides.

------


2. Tied to an "owner" object

Why not just go manual memory. Just store everything
in a tree-like structure.

SuperOwner
--Child1
--Child2
----SubChild1
----SubChild2
------Container1
------Container2
------TStringList

Freeing a Child2 disposes of everything below.