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

[H. S. Teoh via Digitalmars-d-learn]

On Fri, May 26, 2017 at 06:06:42PM +0000, Mike B Johnson via Digitalmars-d-learn 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.

Unfortunately, it can't, because (1) D interfaces with C code, and you
don't have this kind of information from a C object file, and (2) you
can turn a pointer into an int with a cast or a union in @system code,
and since the GC cannot assume @safe for all code, it needs to be
conservative and assume any int-like data could potentially be a
pointer.

You could improve GC performance by giving it type info from @safe code
so that it skips over blocks that *definitely* have no pointers (it
already does this to some extent, e.g., data in an int[] will never be
scanned for pointers because the GC knows it can't contain any). But you
can't make the GC fully non-conservative because it may crash the
program when it wrongly assumes a memory block is dead when it's
actually still live. All it takes is one pointer on the stack that's
wrongly assumed to be just int, and you're screwed.


T

-- 
Dogs have owners ... cats have staff. -- Krista Casada