Orphan ranges

[Dmitry Olshansky]

On 15.04.2012 20:34, 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)
>
Nice overview. I believe there should adapters on top of that.
Say a pool allocator on top of any of these. Same goes for free-list 
which is arguably a limited form of pool allocator.

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

That was the main Q apparently. Potential answers follow.

> For now I have a related question about orphan ranges.
>
> Consider this motivating example:
>
> void main()
> {
> int[] x;
> {
> auto b = new int[20];

Imagine it's an Array!int(20) from here on. And x is a slice type for it.

> x = b[5 .. $ - 5];
> }
> ... use x ...
> }

Here, obviously the ability to use x not thinking at all of b is largely 
a property of GC allocator. I'd call it "any reference suffice" 
property, meaning that no extra effort needed to keep container alive.

Otherwise if say used refcounted scheme then Array *itself* has to be 
aware of the fact its allocator is !any_reference_suffice thus put a an 
extra reference into it's slice.

Now scale-up from this low-level issue. All of the above was written in 
the usual memory-safety-not-negotiable perspective. Call it a policy and 
enact it by default. Now kill all of extra safety hooks and call it 
unsafe-speed-comes-first policy.

The answer then in my opinion that it's *both*. Allocator tells what 
kind of guarantees it has and container then observes if it has to do 
some extra work to ensure his policy stands (e.g. add extra refs to 
allow memory safety for orphan ranges). Because by the end of day it's 
container that provides ranges and thus responsible for this decision.


-- 
Dmitry Olshansky