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] |
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.