At http://www.wikiservice.at/dse/wiki.cgi?GarbageCollection (german
language wiki about software development) I defined "reference counting"
as GC mechanism, but only strictly said.
In common discussion we seperate refcounting from garbage collection and
simplify "Tracing GC" with "GC".
But the word "common" was attacked by C/C++ folks. Do people "commonly"
really put refcounting to GC? This is completely new to me.
GC "usually" means tracing GC (mark-sweep, copying, ... GC's) to me, but
not refcounting.
In which circles do people count refcounting to GC?
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
Reini Urban wrote:
> At http://www.wikiservice.at/dse/wiki.cgi?GarbageCollection (german
> language wiki about software development) I defined "reference counting"
> as GC mechanism, but only strictly said.
> In common discussion we seperate refcounting from garbage collection and
> simplify "Tracing GC" with "GC".
>
> But the word "common" was attacked by C/C++ folks. Do people "commonly"
> really put refcounting to GC? This is completely new to me.
> GC "usually" means tracing GC (mark-sweep, copying, ... GC's) to me, but
> not refcounting.
> In which circles do people count refcounting to GC?
http://www.xanalys.com/software_tools/mm/glossary/g.html#garbage.collection
Refcounting _is_ as you can see really a GC mechanism, but you are true
that in common discussion the Term GC is mainly used for tracing GCs.
I think the reason why the C/C++ folks are screaming on this is because
they mainly use refcounting as a mean for automatic memory management and
therefore can't stand being criticized for "having no GC".
I don't know if it really changes something if they could say they have a
GC if they have some refcounting mechanism because refcounting is known for
being suboptimal for many applications.
Regards,
Jochen
······@sbox.tu-graz.ac.at (Reini Urban) writes:
> At http://www.wikiservice.at/dse/wiki.cgi?GarbageCollection (german
> language wiki about software development) I defined "reference counting"
> as GC mechanism, but only strictly said.
> In common discussion we seperate refcounting from garbage collection and
> simplify "Tracing GC" with "GC".
>
> But the word "common" was attacked by C/C++ folks. Do people "commonly"
> really put refcounting to GC? This is completely new to me.
> GC "usually" means tracing GC (mark-sweep, copying, ... GC's) to me, but
> not refcounting.
> In which circles do people count refcounting to GC?
IMHO, at least in serious discussions, reference counting is usually
named seperately from tracing GC, since reference counting is only
applicable as a stand-alone mechanism in systems without circular
data-structures. This is a very specific restriction, and hence
people like to point this out by naming reference counting explicitly
if they want to include it in some statement on GC.
At least that's my experience, but given that most modern language
implementations are still playing catch-up with the 60s, maybe things
have changed, and we now call each automatic memory management
strategy garbage collection. See Kent M Pitman's Parenthetically
Speaking article "What's in a Name? Uses and Abuses of Lispy
Terminology" at http://world.std.com/~pitman/PS/Name.html for reasons
why people might want to co-opt the term GC...
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Pierre R. Mai" <····@acm.org> writes:
> ······@sbox.tu-graz.ac.at (Reini Urban) writes:
>
> > At http://www.wikiservice.at/dse/wiki.cgi?GarbageCollection (german
> > language wiki about software development) I defined "reference counting"
> > as GC mechanism, but only strictly said.
> > In common discussion we seperate refcounting from garbage collection and
> > simplify "Tracing GC" with "GC".
> >
> > But the word "common" was attacked by C/C++ folks. Do people "commonly"
> > really put refcounting to GC? This is completely new to me.
> > GC "usually" means tracing GC (mark-sweep, copying, ... GC's) to me, but
> > not refcounting.
> > In which circles do people count refcounting to GC?
>
> IMHO, at least in serious discussions, reference counting is usually
> named seperately from tracing GC, since reference counting is only
> applicable as a stand-alone mechanism in systems without circular
> data-structures. This is a very specific restriction, and hence
> people like to point this out by naming reference counting explicitly
> if they want to include it in some statement on GC.
>
> At least that's my experience, but given that most modern language
> implementations are still playing catch-up with the 60s, maybe things
> have changed, and we now call each automatic memory management
> strategy garbage collection. See Kent M Pitman's Parenthetically
> Speaking article "What's in a Name? Uses and Abuses of Lispy
> Terminology" at http://world.std.com/~pitman/PS/Name.html for reasons
> why people might want to co-opt the term GC...
We Lispers should be careful not to get caught up in our own lie.
Many modern generational gcs and also stop-an-copy gcs are not
garbage-collectors at all; they are garbage _leavers_ or live-data
collectors. I may have already said that facetiously in this ng before,
but when it comes to discussions about true meanings of terminology,
I become serious about this distinction, and must point out that we
do live in a glass house.
I would rather we characterize the differences beween ref-counting and
other types of gc by calling the latter "automatic storage reclamation"
and the former "semi-automatic storage reclamation", (and, for
completeness, free (from of the malloc/free pair), which is of course
"manual storage reclamation").
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
>
> We Lispers should be careful not to get caught up in our own lie.
> Many modern generational gcs and also stop-an-copy gcs are not
> garbage-collectors at all; they are garbage _leavers_ or live-data
> collectors. I may have already said that facetiously in this ng before,
> but when it comes to discussions about true meanings of terminology,
> I become serious about this distinction, and must point out that we
> do live in a glass house.
In fact, reference counting is really *more* like a garbage Collector
than most modern GCs, because it does need to walk over huge graphs of
objects as it reduces their reference counts to zero to make them
garbage, while the GCs we normally think of don't (:-)
Actually, are there any good implementations of reference counting on
modern hardware? Any naive approach has to result in hideous memory
traffic and fragmentation, both of which are really expensive.
--tim
From: James Hague
Subject: Re: GC vs refcounting
Date:
Message-ID: <3affe8d8_3@newsfeeds>
Tim Bradshaw wrote:
>
> Actually, are there any good implementations of reference counting on
> modern hardware? Any naive approach has to result in hideous memory
> traffic and fragmentation, both of which are really expensive.
Reference counting is common, though not necessarily for languages like
Lisp, ML, and Prolog, which allocate memory in a fine-grained way (i.e. cons
cells) and in which much data tends to be ephemeral. Strings in both the
C++ Standard Template Library and Borland's Delphi/Kylix are reference
counted. It also makes sense for languages like APL, in which the average
data object tends to have substantial size.
James
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
"James Hague" <···········@volition-inc.com> writes:
>
> Reference counting is common, though not necessarily for languages like
> Lisp, ML, and Prolog, which allocate memory in a fine-grained way (i.e. cons
> cells) and in which much data tends to be ephemeral. Strings in both the
> C++ Standard Template Library and Borland's Delphi/Kylix are reference
> counted. It also makes sense for languages like APL, in which the average
> data object tends to have substantial size.
The first two these cases (which may be good ones) are also viable
because the data structures are such that circularities don't occur.
But you didn't really answer the question I meant to ask (:-). I'm
sure reference counting is used a lot, but does it result in good
performance compared to a more conventional tracing GC?
--tim
Tim wrote:
> But you didn't really answer the question I meant to ask (:-). I'm
> sure reference counting is used a lot, but does it result in good
> performance compared to a more conventional tracing GC?
No. Or -- at least -- when people have measured performance of
reference counting w.r.t. other gc's, it has found to be
seriously wanting. I don't have them to hand, but there are I can
dig them out if you want...
The reason often given for using reference counting is that is is
a form of incremental gc -- reference counting gc is intermingled
with allocation and object reference. However, (as Roger Corman
points out elsewhere in this thread) this shags all those nice
caching tricks that hardware and OS designers like and in general
gives a constant overhead to all variable reference. Bleughhh.
:)will
Will Deakin <········@pindar.com> writes:
>
> The reason often given for using reference counting is that is is
> a form of incremental gc -- reference counting gc is intermingled
> with allocation and object reference. However, (as Roger Corman
> points out elsewhere in this thread) this shags all those nice
> caching tricks that hardware and OS designers like and in general
> gives a constant overhead to all variable reference. Bleughhh.
I think, again, that perhaps this justification works only because
people who use reference counting probably aren't using complex object
graphs. If a reference count changes on something high up in a large
graph then you can get quite noticable pauses (in fact, since it's
basically walking the graph those pauses should be the same as a
conventional GC walking the same graph, except they happen more
often).
--tim
In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
>I think, again, that perhaps this justification works only because
>people who use reference counting probably aren't using complex object
>graphs. If a reference count changes on something high up in a large
>graph then you can get quite noticable pauses (in fact, since it's
>basically walking the graph those pauses should be the same as a
>conventional GC walking the same graph, except they happen more
>often).
Note that the only time it has to walk the graph is when the reference
count changes to zero, not every time the refcount changes.
I think the another reason reference counting is popular is simply because
it's very easy to implement. I think it's common to use refcounts in
version 0.1 of a system, perhaps with a plan to replace it with a more
advanced GC sometime before 1.0. Some systems use both types of GC; I
think I've hear that it's common in Smalltalk implementations to use
refcounts as the primary GC, and occasionally use mark/sweep to get rid of
the dangling circularities.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Tim Bradshaw wrote:
>
> Of course I suspect that in practice almost everything has a count of
> 1, so actually you *do* have to propagate a lot. Certainly the Xerox
> Dmachines (which used reference counting) used to go away for hours
> when counts dropped to 0 at the top of big structures.
>
The D machine GC was indeed pure reference counting, but at least it was
implemented in a manner tuned for Lisp. The primary trick was what you
mentioned above - the observation that almost all refcounts are 1.
Instead of putting a counter in every object, it had two hash tables,
one for zero-reference objects, one for more-than-one-reference
objects. Also, references on the stack were not refcounted, so a GC
blip consisted of sweeping the stack to mark things in the
zero-reference table, then collecting anything that was left.
Dropping a flat list on the floor wouldn't wedge the GC, but dropping
any tree-like structure (like any non-trivial function definition) could
- the first collection would get the top cons, the next one would get
its two children, etc...
Anyone know if the "modern" scripting langauges use a smart refcount GC
like the above?
--
Remove obvious stuff to e-mail me.
Bob Bane
Bob Bane <····@removeme.gst.com> wrote:
: implemented in a manner tuned for Lisp. The primary trick was what you
: mentioned above - the observation that almost all refcounts are 1.
: Instead of putting a counter in every object, it had two hash tables,
: one for zero-reference objects, one for more-than-one-reference
: objects. Also, references on the stack were not refcounted, so a GC
: blip consisted of sweeping the stack to mark things in the
: zero-reference table, then collecting anything that was left.
: Dropping a flat list on the floor wouldn't wedge the GC, but dropping
: any tree-like structure (like any non-trivial function definition) could
: - the first collection would get the top cons, the next one would get
: its two children, etc...
: Anyone know if the "modern" scripting langauges use a smart refcount GC
: like the above?
A smalltalk (which?) used that "deferred refcounting".
but I don't know if they also used the refcount=1 trick, or just the
trick to leave out cheap stack vars.
python 2.0 also claims to have a new "tricky" refcounting based GC.
http//www.enwe.ucalgary.ca/~nascheme/python/gc.html
describes the way to find all unreferenced objects (opposite to a
tracing GC), and detect all cycles which can only occur in python-specific
"containers".
hmm, finalizing: two crosswise referring objects are simple not free'd, as
it happens with perl also. (and is a pain for embedded interpreters).
python folks also claim to "like" refcounting. their pro-refcounting
arguments sound like another urban myth to me.
better locality of reference (which is wrong) besides predictable
finalization (which is true).
perl6 does it right and uses a tracing gc.
--
Reini Urban
http://xarch.tu-graz.ac.at/acadwiki/AutoLispFaq
Reini Urban wrote:
>
>
> python 2.0 also claims to have a new "tricky" refcounting based GC.
> http://www.enme.ucalgary.ca/~nascheme/python/gc.html
> describes the way to find all unreferenced objects (opposite to a
> tracing GC), and detect all cycles which can only occur in python-specific
> "containers".
>
From a quick look at the description (I fixed the link above, BTW), it
really is just a tracing GC with a clever hack to determine a pseudo
root set within Python container space. The implementation of container
tracking with doubly-linked lists doesn't do much for the locality of
reference argument, though; every time you create/reclaim a container,
you have to reach out and mess with the link fields in both its
neighbors.
> python folks also claim to "like" refcounting. their pro-refcounting
> arguments sound like another urban myth to me.
> better locality of reference (which is wrong) besides predictable
> finalization (which is true).
--
Remove obvious stuff to e-mail me.
Bob Bane
Reini Urban <······@x-ray.at> writes:
> Bob Bane <····@removeme.gst.com> wrote:
> : Anyone know if the "modern" scripting langauges use a smart refcount GC
> : like the above?
>
> A smalltalk (which?) used that "deferred refcounting".
These days, the most popular language to use refcounting is probably
Visual Basic. Since they use prompt finalization a lot, I doubt it's
very deferred, though. Even VB is giving up refcounting, as VB.NET
will drop it and use the GC services of the platform.
> python 2.0 also claims to have a new "tricky" refcounting based GC.
> http//www.enwe.ucalgary.ca/~nascheme/python/gc.html
YM <http://www.enme.ucalgary.ca/~nascheme/python/gc.html>.
> hmm, finalizing: two crosswise referring objects are simple not free'd, as
> it happens with perl also. (and is a pain for embedded interpreters).
To clarify, they are only retained if they have finalizers (__del__
methods), otherwise they are freed. The implementors basically got
scared of the finalizer execution order problem, and punted on it.
--
Pekka P. Pirinen, Harlequin Limited
This article printed on 100% recycled electrons.
In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
>··@paradise.nirvananet (Hartmann Schaffer) writes:
>>
>> not necessarily. it should be possible to just add the one cell to the
>> free list and check whether anything hangs off it when you rallocate it
>>
>
>I don't see how this is really different - it just moves the cost from
>freeing to allocation - you have to decrement counts at some point
>between when the object becomes free and when it gets reallocated.
It spreads the cost out, because you never process more than one level at a
time. When an object's count goes to zero, you add it to the free list.
When you reallocate it, you decrement the refcounts of the things it
references. If any of them go to zero you'll add them to the free list,
but you won't recurse any further until one of them gets reallocated.
With the more well known algorithm for doing reference counts, at the time
you free an object you'll recurse immediately as long as you keep
encountering zero refcounts. So if you have a huge data structure that's
only connected to the rest of the world by one pointer, and you drop that
pointer, you'll walk the entire thing adding it to the free list.
Another feature of the incremental approach is that the costs are imposed
on operations that *seem* more costly. Which looks like it should be
cheaper, (setq a (make-array ...)) or (setq a nil)? The latter looks like
it should be trivial, but in a traditional refcounting implementation it
could pause for a while while it frees everything that the array
references.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@genuity.net> writes:
> It spreads the cost out, because you never process more than one level at a
> time. When an object's count goes to zero, you add it to the free list.
> When you reallocate it, you decrement the refcounts of the things it
> references. If any of them go to zero you'll add them to the free list,
> but you won't recurse any further until one of them gets reallocated.
>
Yes. I feel like an idiot now (:-).
--tim
Barry Margolin <······@genuity.net> writes:
> It spreads the cost out, because you never process more than one level at a
> time. When an object's count goes to zero, you add it to the free list.
> When you reallocate it, you decrement the refcounts of the things it
> references. If any of them go to zero you'll add them to the free list,
> but you won't recurse any further until one of them gets reallocated.
>
yes, I feel like an idiot now (:-).
I guess using this technique you can also do a desperation thing of
looking at everything that has been put onto the free list and
decrementing the reference counts of things it references if you run
out of memory, because otherwise you have a whole lot of garbage which
you haven't realised is garbage yet, which normally doesn't matter but
might if you really run out of memory.
--tim
The problem with this approach, it appears to me, is that you can end up in
this sort of desperation mode, and then you're back to substantial pauses.
I think I can construct examples routinely end up in "desperation mode".
(Allocate a multiple MB object, embed it in a deeply nested structure of
small objects, drop the whole thing, repeat.)
We've been down this road a few times on the ······@iecc.com mailing list.
It seems to me that in order to get any sort of guaranteed bound on latency,
you have to both significantly complicate the algorithm, and tolerate a fair
amount of floating garbage, thus reintroducing the space overhead normally
associated with tracing collectors.
Of course, these problems go away if all objects are the same size. At
least one of the early papers on this subject made that assumption. Based
on some of the recent work by Siebert and others on Java (see
http://www.fridi.de/rts/papers/index.html ) that may be more viable than I
would have thought, if you are willing to pay for hard latency guarantees.
It probably doesn't make sense for a general purpose implementation.
If you can deal with cycles, reference counting has both time and space
advantages for very large objects. From what I've seen, it's time
performance for small objects is not that great (and it's pretty bad if you
do it naively, e.g. with C++ "smart pointers") and gets considerably worse
in multithreaded environments. If your hardware supports atomic adds, a
thread-safe reference count increment is probably in the range of 10-30
cycles (20+ on a Pentium II), i.e. up to about 100 times the cost of a
register to register add. If your hardware doesn't, things are worse still
...
Hans-J. Boehm
Hans_Boehm<at>hp<dot>com
Tim Bradshaw <···@tfeb.org> wrote in message
····················@tfeb.org...
> I guess using this technique you can also do a desperation thing of
> looking at everything that has been put onto the free list and
> decrementing the reference counts of things it references if you run
> out of memory, because otherwise you have a whole lot of garbage which
> you haven't realised is garbage yet, which normally doesn't matter but
> might if you really run out of memory.
>
> --tim
In article <···············@tfeb.org>, Tim Bradshaw wrote:
>··@paradise.nirvananet (Hartmann Schaffer) writes:
>>
>> not necessarily. it should be possible to just add the one cell to the
>> free list and check whether anything hangs off it when you rallocate it
>>
>
>I don't see how this is really different - it just moves the cost from
>freeing to allocation - you have to decrement counts at some point
>between when the object becomes free and when it gets reallocated.
> ...
your complaint was that ref counting gcs can lead to as long delays as
tracing gcs, namely when yo free the head of a big linked structure. if
in that case you move only the head to free list, and upon reallocation
move the head of the tail to the free list, you won't have the delay any
more. total work will most likely be the same, but it's distributed so
that it is hardly noticeable
--
hs
----------------------------------------------------------------
"The cheapest pride is national pride. I demonstrates the lack of
characteristics and achievements you can be proud of. The worst loser
can have national pride" - Schopenhauer
On Mon, 14 May 2001 16:47:23 +0100, Will Deakin <········@pindar.com>
wrote:
>The reason often given for using reference counting is that is is
>a form of incremental gc -- reference counting gc is intermingled
>with allocation and object reference. However, (as Roger Corman
>points out elsewhere in this thread) this shags all those nice
>caching tricks that hardware and OS designers like and in general
>gives a constant overhead to all variable reference. Bleughhh.
>
On platforms without scavenging collectors (e.g., C/C++), nearly any
sharing of system resources (files,memory,etc.) could be fodder for
reference counting. This is particularly true if the allocation is
somehow hidden from the application, or if the application cannot be
trusted to free the resource - clearly the case with packaged library
or system code.
More generally, sharing system resources between *programs* (unless
you have a Lisp with multiple waiters ;) demands reference counting.
There just isn't any other reliable way to know when the resource can
be reclaimed.
George
Tim Bradshaw <···@tfeb.org> writes:
> But you didn't really answer the question I meant to ask (:-). I'm
> sure reference counting is used a lot, but does it result in good
> performance compared to a more conventional tracing GC?
FWIW the purely functional language folks at the local Technical
University Berlin use an optimized form of reference counting for the
implementation of their home-grown language OPAL (see
http://uebb.cs.tu-berlin.de/~opal/ for details, reports and
implementations). Reference counting works unaided for purely
functional languages, because it is pretty difficult to create
circular data-structures in them.
When I talked to them a couple of years back on the topic of
performance, they claimed that RC (with a lot of help from the
compiler in optimizing out the actual incf/decf operations where
possible) actually performed quite decently. The compiler
optimizations did reduce the memory bandwidth issues quite a bit
apparently. I don't know what kind of benchmarking they did, or
whether they wrote this up somewhere.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
In my opinion, reference counting is just one of many GC methods. Every GC
method has its pros and cons; some are more complete but pay a price in
performance for this completeness.
If a GC mechanism couldn't be called GC because it misses some things, what
happens to "conservative GC", which is used with conventional languages
that don't support "real GC", like C/C++. GC is in the name, but how much
of the garbage gets collected is non-deterministic (at least with
refcounting the programmer can ensure that he doesn't create dangling
circular references, and many data structure designs don't have circular
references to begin with).
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
On 11 May 2001 16:40:06 +0200, "Pierre R. Mai" <····@acm.org> wrote:
>······@sbox.tu-graz.ac.at (Reini Urban) writes:
>
>> At http://www.wikiservice.at/dse/wiki.cgi?GarbageCollection (german
>> language wiki about software development) I defined "reference counting"
>> as GC mechanism, but only strictly said.
>> In common discussion we seperate refcounting from garbage collection and
>> simplify "Tracing GC" with "GC".
>>...
>IMHO, at least in serious discussions, reference counting is usually
>named seperately from tracing GC, since reference counting is only
>applicable as a stand-alone mechanism in systems without circular
>data-structures. This is a very specific restriction, and hence
>people like to point this out by naming reference counting explicitly
>if they want to include it in some statement on GC.
...
The problems with circular data structures are pretty well understood
by people on this newsgroup, but not generally by C/C++ people (in my
experience). Of course they occur all over the place, but nobody
thinks of them as "circular" (eg. objects with links back to their
parents).
My real problem with using reference counting as memory management is
that it either is not automatic, or does not perform well (or both). I
once built a lisp interpreter using reference counting as the memory
management. To make it fully transparent (as close as possible) I used
C++ smart pointers to pass around everything. Inline code caused the
reference count to increment or decrement more or less automatically,
and it worked correctly. However, it was very slow. I reimplemented it
using a very simple conservative mark/sweep collector, and got an
order of magnitude increase in the performance of the whole system. I
think a generational collector gives another order of magnitude
improvement.
To make reference counting fast, you have to optimize away many of the
increment/decrement operations. Unfortunately this often requires the
programmer to manually modify the code, which makes the collection
less transparent and automatic. If you use manual reference counting,
you essentially have the same problem you have remembering to manually
free memory--you haven't gained anything (eg. COM programming in C++).
Finally, a major problem with reference counting, is that all real
implementations I have seen store the reference count in the object
(this isn't strictly necessary, just convenient). This messes up the
hardware caching and VM management, because you are constantly
modifying objects all over the heap when all you are really doing is
passing and returning, or assigning, pointers to those objects. This
is probably the biggest mark against reference counting as a memory
management tool, in my opinion.
Roger
······@sbox.tu-graz.ac.at (Reini Urban) writes:
> But the word "common" was attacked by C/C++ folks. Do people "commonly"
> really put refcounting to GC? This is completely new to me.
> GC "usually" means tracing GC (mark-sweep, copying, ... GC's) to me, but
> not refcounting.
> In which circles do people count refcounting to GC?
Perhaps in C/C++ circles? In other circles, the disadvantages of
refcounting tend to limit its use, so the need to discuss both rarely
arises. I suspect in practice people use "GC" to mean the GC their
system has, and that would mostly be tracing.
In academic circles, there are of course discussions that range over
the entire spectrum of memory management options, and there the usage
that equates GC to automatic memory management seems to be widespread.
The authority on GC is Jones' _Garbage Collection_,
<http://www.cs.ukc.ac.uk/people/staff/rej/gcbook/gcbook.html>, and it
certainly takes this view. We largely followed this in our Memory
Management Glossary, see
<http://www.xanalys.com/software_tools/mm/glossary/g.html#garbage.collection>.
But arguing about the meaning of "commonly" is silly: the word is
vague, so it can't be said to be wrong. If the readers need to know
more, you should explain, otherwise ignore the kibitzers.
--
Pekka P. Pirinen
A definition tells you something about the way words are used,
not about the way the universe is put together.
- Simon van Dongen <sgvd_pi.net>
On Fri, 11 May 2001 12:20:29 GMT, ······@sbox.tu-graz.ac.at (Reini
Urban) wrote:
>At http://www.wikiservice.at/dse/wiki.cgi?GarbageCollection (german
>language wiki about software development) I defined "reference counting"
>as GC mechanism, but only strictly said.
>In common discussion we seperate refcounting from garbage collection and
>simplify "Tracing GC" with "GC".
>
>But the word "common" was attacked by C/C++ folks. Do people "commonly"
>really put refcounting to GC? This is completely new to me.
>GC "usually" means tracing GC (mark-sweep, copying, ... GC's) to me, but
>not refcounting.
>In which circles do people count refcounting to GC?
Lins and Jones define refcounting as a GC.
At this point in the technology you can pretty much say what
they say goes.
I'm surprised that the C++ folks tend to count refcounting as GC.
The tendency in C++ circles has been to not count refcounting
as GC, because it behaves very differently. If you use GC, you have
to scan all memory even if you only GC one class. In other words
once you use GC on one class you use GC, even if your other classes
don't get collected. With refcounting you can chose to refcount on a
per class basis. The overhead of GC comes in chunks, each time the
collector runs. The overhead of refcounting comes a bit at a time, as
objects are no longer needed. The reclamation in GC is delayed.
In refcounting it is immediate.
The only thing I can think of is that it is a counter reaction to Lins
and Jones. And no, it is not so that they can claim C++ has Jochen
Schmidt says ( unless your C++ crowd is as clueless as he is ). There
are many GC libraries out there for C++, most variants of the Boehm
garbage collector.
Thaddeus L Olczyk wrote:
> I'm surprised that the C++ folks tend to count refcounting as GC.
> The tendency in C++ circles has been to not count refcounting
> as GC, because it behaves very differently. If you use GC, you have
> to scan all memory even if you only GC one class. In other words
> once you use GC on one class you use GC, even if your other classes
> don't get collected. With refcounting you can chose to refcount on a
> per class basis. The overhead of GC comes in chunks, each time the
> collector runs. The overhead of refcounting comes a bit at a time, as
> objects are no longer needed. The reclamation in GC is delayed.
> In refcounting it is immediate.
Refcounting is immediate but may pause longer too. The removal of one
reference may cause the recycling of a large number of objects. Therefore
RC has similar problems like tracing GC when working in realitime
environments.
> The only thing I can think of is that it is a counter reaction to Lins
> and Jones. And no, it is not so that they can claim C++ has Jochen
> Schmidt says ( unless your C++ crowd is as clueless as he is ). There
> are many GC libraries out there for C++, most variants of the Boehm
> garbage collector.
Do you meant me when speaking of clueless?
Jochen Schmidt,
--
http://www.dataheaven.de
······@sbox.tu-graz.ac.at (Reini Urban) writes:
> In which circles do people count refcounting to GC?
Not in the circles that cannot be reclaimed by refcounting I guess.
--
Janis Dzerins
If million people say a stupid thing it's still a stupid thing.