Orphan ranges

[Andrei Alexandrescu]

On 4/15/12 12:50 PM, Chad J wrote:
> How about
> * User-defined allocator
> ??

Yah, the allocator would be a generic parameter. Any allocator that 
supports a compatible interface with the archetypes used would work. But 
making e.g. file-backed allocators or whatnot may be difficult.

> 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".

Makes sense.

> 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.

So orphans should be allowed. Wonder if that should be an option or just 
"it".

> 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.

Agreed. RC is not that difficult, and implementing it in terms of 
containers should be doable pretty nicely.

> 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)

Sounds great. There's quite a few difficulties along the road, but I 
think the roadmap is good.


Andrei