Question to GC experts: NO_SCAN for a part of the block

[Stanislav Blinov via Digitalmars-d]

On Sunday, 4 June 2017 at 09:38:45 UTC, ag0aep6g wrote:

>> Should this work, and if not, why?
>
> As far as I can tell, the `addRange` call works correctly, but 
> maybe too well in a sense. It keeps the `new`ed `C`s alive as 
> long as `arrays3.Cs` has pointers to them. And `arrays3.Cs` has 
> those pointers until the very end.

Yeah, after playing around with the code a bit, shuffling the 
calls, making new allocations, etc., I saw those dtors indeed 
being run. I was just expecting the behavior to be the same as 
for normal 'new'ed arrays, but I guess there are nuances.

> If you add `GC.removeRange(arrays3.Cs.ptr);` at the of `main`, 
> the dtors show up.

Yeah, well, calling it manually sort of defeats the purpose :)

> Overwriting `arrays3.Cs`'s elements with `null`s also works. My 
> guess is that the `removeRange` call isn't done automatically 
> before the final run of the GC. Maybe it should be?

If at all possible, I think that'd be good, if only for 
consistency.

> But I have a vague memory that the GC isn't required to call 
> destructors on everything in the final run. Or maybe it's not 
> guaranteed that there is a final run when the program ends?

That's what puzzled me, seeing as dtors from the other two arrays 
ran at the end. I understand how particular dtors may not be run 
due to circular or self-references, but there are none in this 
case.

> Anyway, that would mean everything's working as intended, and 
> you just can't rely on destructors like that.

Seems it is, and that is great. Now all that's left is some 
benchmarking to see if saving on allocations actually yields any 
fruit.

Thanks!