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.
