delete and references?

[Jeremie Pelletier]

Jarrett Billingsley Wrote:

> On Sat, Aug 8, 2009 at 9:42 AM, Andrei
> Alexandrescu<SeeWebsiteForEmail at erdani.org> wrote:
> > Jarrett Billingsley wrote:
> >>
> >> On Sat, Aug 8, 2009 at 9:17 AM, Andrei
> >> Alexandrescu<SeeWebsiteForEmail at erdani.org> wrote:
> >>>
> >>> FWIW, I am trying to convince Walter to not reclaim memory in delete, but
> >>> instead only call destructors. D continues C++'s mistake of conflating
> >>> lifetime termination with memory reclamation.
> >>
> >> Why?  Instead of dangling pointers, you'd end up with pointers to
> >> finalized objects, which would probably lead to harder-to-catch bugs
> >> (since then you wouldn't even get a segfault).
> >
> > Getting a segfault == lucky
> 
> And the alternative - using a "dead" object - is any better?
> 
> >> And what if you used it to try to delete a temporary array?  Yes, you
> >> could use malloc/free for the temp array, but.. it just seems silly to
> >> have to dip into C functions to do that.
> >
> > Why? It's not a frequent need.
> 
> That's enough of a justification to change delete's behavior?
> 
> I just don't know why it should be changed.  It's a blunt tool for
> blunt uses.  When you delete something, you're telling the GC "I don't
> need this anymore, *trust me*", so *not* freeing memory associated
> with it seems silly.

I just had an idea for new semantics for delete. With proper use it could speed up the GC a lot, and with misuse it could make it worse.

When deleting memory, that block goes on a special linked list with an internal entry wrapper as to not alter the memory. It is not finalized, nor is its GC state changed (has pointers, no scan, etc). Once the GC is asked to do a sweep, that linked list is checked first for unused memory, and free blocks are put back on the freelist. If enough can be reclaimed there for the allocation request which triggered the sweep, the entire set of allocations doesn't have to be scanned.

Well thats the idea in a nutshell, it popped in my mind as I read Andrei's comment about delete doing only a finalize. Since we don't have a moving GC with multiple heaps (short lived heap moving up to long lived heap, and only the short lived one is scanned often), we could optimize how the sweep is being done.

That would however require new ABI routines to use with do-it-now deletes, such as scoped allocations as their usage may rely on the fact that the finalizer is executed when the scope exits.

Please give me some input on that idea.