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