Out of memory error (even when using destroy())

[Stanislav Blinov via Digitalmars-d-learn]

On Friday, 26 May 2017 at 18:06:42 UTC, Mike B Johnson wrote:
> On Friday, 26 May 2017 at 14:05:34 UTC, ag0aep6g wrote:
>> On 05/26/2017 10:15 AM, realhet wrote:
>>> But hey, the GC knows that is should not search for any 
>>> pointers in those large blocks.
>>> And the buffer is full of 0-s at the start, so there can't be 
>>> any 'false pointers' in it. And I think the GC will not 
>>> search in it either.
>>
>> The issue is not that the block contains a false pointer, but 
>> that there's a false pointer elsewhere that points into the 
>> block. The bigger the block, the more likely it is that 
>> something (e.g. an int on the stack) is mistaken for a pointer 
>> into it.
>
> Wow, if that is the case then the GC has some real issues. The 
> GC should be informed about all pointers and an int is not a 
> pointer.

What is a pointer if not an int? :)

That is not an issue. The GC holds off releasing memory if 
there's even a suspicion that someone might be holding on to it. 
In most problems, ints are small. Pointers are always big, so 
there's not much overlap there. Accidents do happen occasionally, 
but it's better to have a system that is too cautious than one 
that ruins your data.

Working with huge memory chunks isn't really a domain for GC 
though.