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

[Stanislav Blinov via Digitalmars-d-learn]

On Saturday, 27 May 2017 at 17:57:03 UTC, Mike B Johnson wrote:

> And what if one isn't interfacing to C? All pointers should be 
> known. You can't access memory by and int or any other 
> non-pointer type! Hence, when pointers are created or ints are 
> cast to pointers, the GC should be informed and then handle 
> them appropriately

Eh? So *every* cast from and to a pointer should become a call 
into the runtime, poking the GC? Or rather, every variable 
declaration should somehow be made magically known to the GC 
without any runtime cost?

> (then, instead of scanning a 100MB block of memory for 
> "pointers" it should scan the list of possible pointers(which 
> will generally be much much lower).

That's precisely what it does, it scans the possible suspects, 
nothing more. That is, the stack (it has no idea what's there, 
it's just a block of untyped memory), memory it itself allocated 
*only if* it needs to (e.g. you allocated a typed array, and the 
type has pointers), memory you've specifically asked it to scan. 
It won't scan that block of 500k ints the OP allocated, unless 
told to do so. It would scan it if it was a void[] block though.

> Therefor, in a true D program(no outsourcing) with no pointers 
> used, the GC should never have to scan anything.

No pointers used? No arrays, no strings, no delegates?.. That's a 
rather limited program. But thing is, you're right, in such a 
program the GC will indeed never have to scan anything. If you 
never allocate, GC collection never occurs either.

> It seems the GC can be smarter than it is instead of just 
> making blanket assumptions about the entire program(which 
> rarely hold), which is generally always a poor choice when it 
> comes to performance...

Unnecessary interaction with the GC, e.g. informing it about 
every cast, is a poor choice for performance.

> After all, if we truly want to be safe, why not scan the entire 
> memory of the system? Who knows, some pointer externally might 
> be peeping in on our hello world program.

What?