On Wed, 30 Apr 2014 14:15:03 -0400, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:

> 30-Apr-2014 19:33, Andrei Alexandrescu пишет:

>> 4. Currently, struct objects created with new do NOT have their
>> destructors called during collection. I think this may continue, meaning
>> that structs created with new are somewhat low-level and are meant to be
>> destroyed and deallocated manually.

I think structs can and will be destructed from the heap at some point. What we do need, however, is some more intelligence in GC destruction. Assumptions don't cut it, especially in multi-threaded code.

> IIRC they do, it's only arrays of such that doesn't. Anyhow having such a dangerous construct built-in (new = resource leak) in the language becomes questionable.

No, they don't. Only objects are marked as having a finalizer. The finalize flag in the GC assumes that the first size_t in the block is a pointer to a vtable. A struct cannot have this.

We need to fundamentally modify how this works if we want finalizers for structs to be called, but I think it's worth doing. IIRC, Rainer's precise GC does this.

>> 5. This brings up arrays of structs. As far as I understand, destructors
>> will never be called for these, even after all references are gone:
>>
>> struct S { ~this() { ... } }
>> auto a = new S[100];
>>
>> Unlike (4), arrays of structs are high-level and frequently used. I
>> think we must do something about it, so I plan to support calling
>> destructors for arrays of structs.

An array of structs is a struct itself, and not a class. While it could conceivably be done much easier than structs with the current layout, it would eliminate 16-byte arrays, because the first size_t would have to be reserved! Hopefully my explanation above helps to understand this.

> Making the point about NOT calling destructor that much more schizophrenic. Either do it properly or not at all.

Agree.

-Steve

On Wed, 30 Apr 2014 20:08:03 -0400
Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> On Wed, 30 Apr 2014 14:15:03 -0400, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:
> 
> > IIRC they do, it's only arrays of such that doesn't. Anyhow having such a dangerous construct built-in (new = resource leak) in the language becomes questionable.
> 
> No, they don't. Only objects are marked as having a finalizer. The finalize flag in the GC assumes that the first size_t in the block is a pointer to a vtable. A struct cannot have this.
> 
> We need to fundamentally modify how this works if we want finalizers for structs to be called, but I think it's worth doing. IIRC, Rainer's precise GC does this.

It would be _very_ cool if we could make it so that struct destructors get run when they're on the GC heap. I'm sure that the fact that they're not called currently creates a number of subtle bugs when structs are used which assume that they're destructor is going to be called when they're destroyed/freed.

- Jonathan M Davis

Am Wed, 30 Apr 2014 08:33:25 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@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

On 5/4/14, Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> 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.
>

That should work independent of what the GC decides to do, as it should be getting emitted as a literal pointer to "hello\n" in the RO data-segment.