On 04/15/2012 12:34 PM, Andrei Alexandrescu wrote:
I'm making good progress on an allocator design. If things come together
as I hope, it'll kick some serious ass.
I'm currently looking at four allocation models:
* straight GC, safe (no deallocation)
* GC + the ability to free memory
* malloc/free, unsafe, buyer beware (STL-level safety)
* reference counted (based on either malloc or GC+free)
* region (scoped)
I need to kink out a few details, most important being - is safety part
of the allocator or an extricable property that's a different policy?
For now I have a related question about orphan ranges.
...
Thanks,
Andrei
How about
* User-defined allocator
??
At the very least, I think we should be able to choose from the above
strategies for a given container. If this isn't done, then there will
always be people wanting to re-implement the containers just to
accomplish silly stuff like allocating a little differently.
As for safety:
I would probably want to be able to tweak the ways my containers are
safe/unsafe. I'd want safety by default, with the ability to choose my
vulnerabilities. "Safety" is a fairly vague notion, since there are a
number of things that could cause memory corruption or undefined
behavior. Allowing me to decide which risk factors to take allows me to
decide which causes of corruption/undefined behavior I want to expose
myself to. Once there's a sufficiently large panel of twiddley knobs
and toggle switches, then it might make sense to create "policies" like
"safe" vs "blazing fast".
As for orphan ranges:
I've always written under the assumption that an array like 'x' would
keep 'b' around. It would be nice if large amounts of memory wasted
from orphans could be reused in some way, but not at the expense of a
lot of speed. If large waste from orphans sticks around, a warning in
the docs would be nice.
Other note:
For the longest time I've thought that D should do reference counting
for types that can be proven to have no reference cycles. I don't
understand why this is difficult, but even if it is it might be worth
it. I don't actually need it personally, but I constantly hear
complaints about "oh, D requires garbage collection because you can't
use most of Phobos without it". What they really want, I bet, is
deterministic memory management for realtime systems that does not cause
thread contention/world stops. Add reference counting and this will
suddenly be doable for what I'd image would be a lot of important stuff
in Phobos (think CoW string functions--probably reference counter
friendly). At this point the "reference counted" option gets subsumed
into the "straight GC" / "GC+free" options, because the
language/compiler would decide at compile-time which strategy to use for
a range.
I see D's current coverage of memory management techniques looking like
this:
- GC garbage collection: allocation for objects with complicated
lifespans, with the caveat of complex allocation/deallocation code
(check, not %100 featureful)
- malloc/free for mediocre-speed allocation of objects whose lifespans
can't be easily calculated but are known by the programmer (check)
- custom allocators for when everything else fails (check, in most cases)
- memory reuse with slices/immutability which gives us an awesome
zero-overhead solution in a number of situations (check)
- reference counting for almost-deterministic allocation of objects with
easily calculated lifespans (**D does not cover this case!**)
- stack for fast allocation of short-lived objects (check)
