This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: forcing guile to collect *all* garbage?


Greg Harvey <Greg.Harvey@thezone.net> writes:

> Michael Livshin <mike@olan.com> writes:
> 
> > In general, you should not assume that GC guarantees that all
> > unreferenced objects are freed.  GC's job is to automate memory
> > management for you, no more and no less.  If you want reliable
> > deallocation, use other means (i.e. deallocate things explicitly in
> > one way or another).  That said, Guile's current GC _can_ be relied
> > upon to scan and free everything.  It's not something you should
> > expect to remain true forever, though.
> 
> Well, it should always free all free objects... it's whether they're
> promptly freed (or, in fact, would be freed in our lifetime ;) that's
> the issue, and gc's don't really make any kind of guarentee on the
> lifetime of dead objects, just that they should eventually be finished
> off.

No.  GC does its job well if my program doesn't run out of memory.  If
the GC chooses to keep some objects forever because bothering with
them would be inefficient, fine.  If a conservative GC never frees
some object because something on the stack looks like a pointer to it,
fine.  I don't want to know how the GC does it's magic.  I don't want
to open the black box.  The GC's contract doesn't explicitly include
object deallocation, though GC *may* deallocate objects to do its job.

If you want something a la C++'s "resource acquisition is allocation"
pattern, don't assume that GC will help you here.

I'm not sure we disagree, actually ;).

> Greg

mike.