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.
One can already choose their own memory model in their own code.
The issue is with the core library and pre-existing code that
forces you to use the GC model.
@nogc has been proposed several years ago but not gotten any
footing. By having the ability to mark stuff has @nogc phobos
could be migrated slowly and, at least, some libraries would be
weaned off the GC and available.
I think the use of custom allocators would be better. Plug your
own memory management model into D.
IMHO nothing will be done because this kinda talk has been going
on for years(nearly a decade it as some posts go back to 2006).
