GC interpreting integer values as pointers
schveiguy at yahoo.com
Thu Oct 14 07:11:37 PDT 2010
On Sat, 09 Oct 2010 15:51:37 -0400, Ivo Kasiuk <i.kasiuk at gmx.de> wrote:
> 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:
> 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
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.
More information about the Digitalmars-d-learn