How the GC distinguishes code from data

Steven Schveighoffer schveiguy at
Wed Jan 5 14:03:38 PST 2011

On Wed, 05 Jan 2011 16:56:47 -0500, Simen kjaeraas  
<simen.kjaras at> wrote:

> %u <wfunction at> wrote:
>> If I have a large uint[], it's practically guaranteed to have data that  
>> looks like pointers, and that might cause memory leaks.
> If you have allocated a large uint[], most likely ìt will be flagged
> NO_SCAN, meaning it has no pointers in it, and the GC will ignore it.

There is another problem that I recently ran into.  If you allocate a  
large memory block, even one marked as not containing pointers, there is a  
medium probability that a 'fake' pointer exists that points *at* that  
block, not from it.  This means that uint[] may never get collected unless  
you manually free it.

>> Furthermore, if the GC moves
>> things around, it would corrupt my data. How is this handled?
> The current GC does not move things. One could write such a GC for D (I
> believe), and in such a case data would be marked NO_MOVE if for whatever
> reason it cannot be moved.

A moving GC cannot exist without precise scanning.  Anything that is  
marked from a conservative block (one that has no pointer map) would not  
be able to move.


More information about the Digitalmars-d-learn mailing list