More radical ideas about gc and reference counting

[Steven Schveighoffer via Digitalmars-d]

On Sun, 11 May 2014 16:33:04 -0400, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> On 5/11/2014 2:48 AM, Benjamin Thaut wrote:
>> Mostly percise doesn't help. Its either fully percise or beeing stuck  
>> with a
>> impercise mark & sweep.
>
> This is not correct. It helps because most of the false pointers will be  
> in the heap, and the heap will be accurately scanned, nearly eliminating  
> false references to garbage.

It doesn't matter where the false pointers are. The largest issue with  
false pointers is not how many false pointers there are. It only matters  
how large the block is that it "points" at. The larger your blocks get,  
the more likely they are "pointed" at by the stack. On 32-bit systems,  
allocate 1/256th of your memory space (i.e. 16.5MB), and the likelihood of  
random data on the stack pointing at it is roughly 1/256. This problem is  
just about eliminated with 64-bit pointers.

> Yes. D, for example, requires that objects not be self-referential for  
> this reason.

As previously stated, self referencing does not preclude GC moving. This  
statement is simply false, you can self reference in D for objects. You  
cannot for structs, but not because of a possibility for the moving GC,  
but because of the requirement to be able to move a struct instance.

And in fact, even if it's forbidden, "requires" is too strong a word --  
there is no static or runtime prevention of this.

-Steve