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.
