Proposal : allocations made easier with non nullable types.

[Leandro Lucarella]

Andrei Alexandrescu, el  9 de febrero a las 22:20 me escribiste:
> Chad J wrote:
> >Andrei Alexandrescu wrote:
> >>Chad J wrote:
> >>>Besides safety concerns, what does forbidding manual deletion enable GC
> >>>implementations to do?
> >>Foregoing delete affords the GC more implementation options.
> >>
> >>Andrei
> >Such as?
> >I'm not trying to be antagonistic--manual deletion is a nifty feature to
> >me, so if it gets designed away I'd appreciate knowing what great
> >advantages justified such a sacrifice.
> 
> You need to simply go through a good tutorial on GC implementations, and consider 
> the added costs of offering a manual delete primitive.

I did read "Garbage Collection: Algorithms for Automatic Dynamic Memory
Management"[1] (several times =P) and some papers on the subject and
I honestly don't recall any big issues about it. The only case I can think
of if copy/compacting collectors that use the heap as a stack when
allocating, where freeing a cell in the middle clearly breaks the stack
allocation.

But in such cases I think delete could be a NOP, just like for now
genCollect() really do a fullCollect() because no generational collection
is present at the moment, the interface is there.

[1] http://www.cs.kent.ac.uk/people/staff/rej/gcbook/gcbook.html

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
More people die from a champagne-cork popping,
than from poison spiders