A few considerations on garbage collection

[Marco Leise via Digitalmars-d]

Am Wed, 30 Apr 2014 08:33:25 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:

> I'm mulling over a couple of design considerations for allocators, and 
> was thinking of the following restriction:
> 
> 1. No out-of-bounds tricks and no pointer arithmetic. Consider:
> 
> int[] a = new int[1000];
> int* p = a[500 .. $].ptr;
> a = a[250 .. 750];
> 
> Subsequently the GC should be within its rights to deallocate any memory 
> within the first and last 250 integers allocated, even though in theory 
> the user may get to them by using pointer arithmetic.

I see that you are trying to account for allocator designs
that could reuse these memory fragments.
If this is for @safe, then maybe some memory could be released,
but you'd have to statically verify that internal pointers
don't make it into unsafe code where I wonder if any memory
would be released if I wrote:

	size_t length = 100;
	int* p = (new int[](length)).ptr;
	GC.collect();
	p[length-1] = 42;

So it is difficult to give a good answer. I'd say no until it
is clear how it would work outside of @safe.

> 6. The point above brings to mind more radical possibilities, such as 
> making all arrays reference-counted and allowing compulsive deallocation 
> when the reference counter goes down to zero. That would rule out things 
> like escaping pointers to data inside arrays, which is quite extreme.

Would that affect all arrays, only arrays containing structs
or only affect arrays containing structs with dtors?

	printf("hello\n".ptr);

should still work after all.

-- 
Marco