Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Richard Jones <R.E.Jones <at> kent.ac.uk>
Subject: Re: Promptness of collection
Newsgroups: gmane.comp.programming.garbage-collection.general
Date: Wednesday 13th March 2013 10:42:52 UTC (over 4 years ago)
On 13 Mar 2013, at 09:20, [email protected] wrote:

On 12/3/13 11:08 AM, Eliot Moss wrote:

> 
> On 3/12/2013 10:45 AM, Jon Harrop wrote:
> 
>> My impression is that even scope-based reference
>> counting (e.g. C++ smart pointers) produces more floating garbage than a
>> simple generational mark-sweep collector.
> 
> How could this be? A mark-sweep collector cannot reclaim
> an object while it is referenced, and (unless you have a
> lot of smarts in an optimizing compiler or something) the
> reference persists until the scope is exited.  Presumably
> when reference counting, an explicit assignment of null
> will decrement the reference count immediately.

Well, let's see if there's a way that this could be true. Compare a simple
two-generation collector with a fixed size nursery with a simple deferred
reference counter. Suppose there are no cycles, no finalisation, etc. Note
that DRC will not free all garbage immediately but periodically stops the
world and processes the roots. Suppose the volume of live objects at the
time of a collection is  "livesize".  In these cases, the generational
collector will reclaim garbage in the nursery after NURSERY_SIZE allocation
whereas the DRC collector will reclaim all garbage after (HEAP_SIZE -
livesize) allocation. It's entirely likely that NURSERY_SIZE < HEAP_SIZE -
livesize so the generational collector might collect *some* but not all
garbage more promptly than the DRC collector. But I think this is not a
particularly profitable avenue to explore...

More importantly, note also that even an immediate (i.e. non deferred)
reference counter cannot reclaim objects as soon as they are no longer
referenced as finalisation must be asynchronous (see Hans Boehm's POPL03
paper "Destructors, finalizers and synchronization", http://dl.acm.org/citation.cfm?doid=604131.604153.

Richard
 
CD: 2ms