On Sat, 09 Oct 2010 15:51:37 -0400, Ivo Kasiuk <i.kas...@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

Reply via email to