More radical ideas about gc and reference counting

[Steven Schveighoffer via Digitalmars-d]

On Mon, 12 May 2014 13:52:20 -0400, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> On 5/12/2014 7:46 AM, Steven Schveighoffer wrote:
>> 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.
>
> Generally, it is a bad idea to allocate such large blocks on the GC  
> heap. GC's work best when the size of the objects being allocated is  
> very small relative to the size of the heap space.
>
> Fortunately, it's a mathematical inevitability that large allocations  
> relative to the GC size are rare, and so it isn't much of a pain to  
> handle them manually.

The issue arises when one allocates such a large block for temporary use  
repeatedly, but expects it to be collected between allocations. The  
consequences are extremely disastrous.

The workaround is simply to keep it around, but that's not always a  
scalable solution.

>> And in fact, even if it's forbidden, "requires" is too strong a word --  
>> there is
>> no static or runtime prevention of this.
>
> It's still forbidden. Andrei wrote a template that will verify this at  
> runtime, but I don't recall its name.

Can you cite the spec where it says it's forbidden? Forgotten templates  
are not a convincing argument.

Regardless, Java can use a moving GC, and allows self references. The idea  
that self references prevent a moving GC is simply false. If you think  
about it a bit, you will understand why.

-Steve