GC interpreting integer values as pointers

[Steven Schveighoffer]

On Sat, 09 Oct 2010 15:51:37 -0400, Ivo Kasiuk <i.kasiuk at gmx.de> wrote:

> Hi!
>
> In my D programs I am having problems with objects not getting finalised
> although there is no reference anymore. It turned out that this is
> caused by integers which happen to have values corresponding to pointers
> into the heap. So I wrote a test program to check the GC behaviour
> concerning integer values:
>

[snip]

> So in most but not all situations the integer value keeps the object
> from getting finalised. This observation corresponds to the effects I
> saw in my programs.
>
> I find this rather unfortunate. Is this known, documented behaviour? In
> a typical program there are such integer values all over the place. How
> should such values be stored to avoid unwanted interaction with the GC?

Yes, D's garbage collector is a conservative garbage collector.  One which  
doesn't have this problem is called a precise garbage collector.

There are two problems here.  First, D has unions, so it is impossible for  
the GC to determine if a union contains an integer or a pointer.

Second problem is the granularity of scanning.  A memory block is scanned  
as if every n bits (n being your architecture) is a pointer, or there are  
no pointers.  This is determined by a bit associated with the block (the  
NO_SCAN bit).

If you allocate a memory block that contains at least one pointer, then  
all the words in the memory block are considered to be pointers by the  
GC.  There is a (continually updated) patch which allows the GC to be  
semi-precise.  That is, the type information of the memory block will be  
linked to it.  This will allow precise scanning except for unions.  Once  
this is integrated, the false pointer problem will be much less prevalent.

-Steve