Another term instead of GC

40 views
Skip to first unread message

Joe Seigh

unread,
Jul 8, 2006, 8:24:02 AM7/8/06
to
I've been using the term GC (garbage collection) to cover
things like RCU, SMR hazard pointers, and possibly reference
counting. The problem is there are too many people who think
GC only means Boehm style tracing and are clue impervious to
other possibilities which makes any discussion on GC rather
skewed and lop sided.

Hopefully the new term would emphasize the multi-threaded
shared aspect of it instead of a memory reclamation scheme
for programmers too lazy to write dtors and who want a "mommy"
to pick up after them.

Maybe something involving data state safety. I'd stay away from
just plain type safety as proposed by Andrei Alexandrescu on
c.l.c++.m since there seemed to be some confusion of the role
of dtors and finalizers and when and where they would run.

Any ideas? You'd get to invent a new term for compsci.

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

Barry Kelly

unread,
Jul 8, 2006, 8:59:36 AM7/8/06
to
Joe Seigh <jsei...@xemaps.com> wrote:

> I've been using the term GC (garbage collection) to cover
> things like RCU

Can you explain why you consider RCU a general automatic collection
technique?

> SMR hazard pointers,

Ditto?

> and possibly reference
> counting.

Reference counting is well accepted as a bona fide GC technique. I'm not
sure why you qualify it with "possibly".

> The problem is there are too many people who think
> GC only means Boehm style tracing

Boehm-style tracing isn't the most common thing that people think of
when they think of GC, IMHO. Rather it's Java and .NET, neither of which
use conservative techniques like the Boehm-Demers-Weiser collector.

> Hopefully the new term would emphasize the multi-threaded
> shared aspect of it instead of a memory reclamation scheme
> for programmers too lazy to write dtors and who want a "mommy"
> to pick up after them.

I don't understand. GC is more efficient than destructors and similar
manual memory reclamation techniques. Destructors are still useful for
reclaiming other resources.

> Maybe something involving data state safety. I'd stay away from
> just plain type safety as proposed by Andrei Alexandrescu on
> c.l.c++.m since there seemed to be some confusion of the role
> of dtors and finalizers and when and where they would run.

Finalizers are only an issue when people try to use GC for resources
other than memory. It's only designed for memory. People have
piggybacked on GC to try and reclaim other resources too - not a good
idea, but it can improve reliability in certain situations.

-- Barry

--
http://barrkel.blogspot.com/

David Hopwood

unread,
Jul 8, 2006, 9:15:01 AM7/8/06
to
Joe Seigh wrote:
> I've been using the term GC (garbage collection) to cover
> things like RCU, SMR hazard pointers, and possibly reference
> counting. The problem is there are too many people who think
> GC only means Boehm style tracing and are clue impervious to
> other possibilities which makes any discussion on GC rather
> skewed and lop sided.

That itself is a rather lop-sided description of the situation.
The term "garbage collection" has been used in a computing context
since the early 1960s (when Hans Boehm was a small child :-), almost
always to mean tracing. "Automatic memory management" is sometimes
used for a more general class of techniques that include GC and
reference counting, although it may not be appropriate for RCU and
SMR.

> Hopefully the new term would emphasize the multi-threaded
> shared aspect of it instead of a memory reclamation scheme
> for programmers too lazy to write dtors and who want a "mommy"
> to pick up after them.

Just a suggestion, but you might want to try expressing your
question in a way that is less likely to ... irritate ... many
of the people who might have an answer to it.

--
David Hopwood <david.nosp...@blueyonder.co.uk>

Joe Seigh

unread,
Jul 8, 2006, 9:59:54 AM7/8/06
to
Barry Kelly wrote:
> Joe Seigh <jsei...@xemaps.com> wrote:
>
>
>>I've been using the term GC (garbage collection) to cover
>>things like RCU
>
>
> Can you explain why you consider RCU a general automatic collection
> technique?
>
>
>>SMR hazard pointers,
>
>
> Ditto?
>
>

A lot of lock-free algorithms generally rely on some mechanism to
determine when memory objects are no longer referenced. While
GC would seem to fit the bill, it has the problems I've mentioned.


>>and possibly reference
>>counting.
>
>
> Reference counting is well accepted as a bona fide GC technique. I'm not
> sure why you qualify it with "possibly".

Except all discussions in the c++ newsgroups especially seem to relegate
reference counting to smart pointers and not a form of general GC. If
they're discussing support by c++ for GC, it's for tracing style GC, not
anything else.

>
>
>>The problem is there are too many people who think
>>GC only means Boehm style tracing
>
>
> Boehm-style tracing isn't the most common thing that people think of
> when they think of GC, IMHO. Rather it's Java and .NET, neither of which
> use conservative techniques like the Boehm-Demers-Weiser collector.

Ok, strike the use of the term Boehm-style. Strike tracing also.
Just plain GC.

>
>
>>Hopefully the new term would emphasize the multi-threaded
>>shared aspect of it instead of a memory reclamation scheme
>>for programmers too lazy to write dtors and who want a "mommy"
>>to pick up after them.
>
>
> I don't understand. GC is more efficient than destructors and similar
> manual memory reclamation techniques. Destructors are still useful for
> reclaiming other resources.

Fine but it doesn't address the sharing aspect.

>
>
>>Maybe something involving data state safety. I'd stay away from
>>just plain type safety as proposed by Andrei Alexandrescu on
>>c.l.c++.m since there seemed to be some confusion of the role
>>of dtors and finalizers and when and where they would run.
>
>
> Finalizers are only an issue when people try to use GC for resources
> other than memory. It's only designed for memory. People have
> piggybacked on GC to try and reclaim other resources too - not a good
> idea, but it can improve reliability in certain situations.
>

Nonetheless, it remained an unresolved issue in the c++ discussions.
And I don't want to resolve it here. Just coin a new term.

Joe Seigh

unread,
Jul 8, 2006, 2:20:35 PM7/8/06
to
An example to start off

SMSM (shared memory state management or manager)

And to clarify, GC and reference counting would
only be a part of whatever we call it if they
were thread-safe.

David Hopwood

unread,
Jul 8, 2006, 3:40:40 PM7/8/06
to
Joe Seigh wrote:
> An example to start off
>
> SMSM (shared memory state management or manager)
>
> And to clarify, GC and reference counting would
> only be a part of whatever we call it if they
> were thread-safe.

So why not call it just "thread-safe memory management", or
"concurrency-safe memory management"?

This would avoid excluding memory management techniques for
concurrency models that do not use shared state, but that have
the same or stronger safety properties, and similar expressiveness.

--
David Hopwood <david.nosp...@blueyonder.co.uk>

gottlo...@gmail.com

unread,
Jul 11, 2006, 1:01:20 PM7/11/06
to

Joe Seigh wrote:
> I've been using the term GC (garbage collection) to cover
> things like RCU, SMR hazard pointers, and possibly reference
> counting. The problem is there are too many people who think
> GC only means Boehm style tracing and are clue impervious to
> other possibilities which makes any discussion on GC rather
> skewed and lop sided.
>

> Maybe something involving data state safety.

>


> Any ideas? You'd get to invent a new term for compsci.
>
> --
> Joe Seigh
>

Are we talking about things like putting a link-list node onto a 'to be
freed' list but not freeing it until no other thread is accessing it?

'free-handing' would be a boring term, without much context (could
instead say 'thread-safe free handling' but it is a bit long). Also
not much different than GC, but it does sound more low-level.

I'd be tempted to think along the lines of 'rug-maintenance' since what
happens when you free something too soon is that the rug gets pulled
out from under the other threads...

Tony

Chris Thomasson

unread,
Jul 11, 2006, 7:35:22 PM7/11/06
to
<gottlo...@gmail.com> wrote in message
news:1152637280.7...@m79g2000cwm.googlegroups.com...

>
> Joe Seigh wrote:
>> I've been using the term GC (garbage collection) to cover
>> things like RCU, SMR hazard pointers, and possibly reference
>> counting. The problem is there are too many people who think
>> GC only means Boehm style tracing and are clue impervious to
>> other possibilities which makes any discussion on GC rather
>> skewed and lop sided.
>>
>
>> Maybe something involving data state safety.
>
>>
>> Any ideas? You'd get to invent a new term for compsci.
>>
>> --
>> Joe Seigh
>>
>
> Are we talking about things like putting a link-list node onto a 'to be
> freed' list but not freeing it until no other thread is accessing it?

Basically...


> 'free-handing' would be a boring term, without much context (could
> instead say 'thread-safe free handling' but it is a bit long). Also
> not much different than GC, but it does sound more low-level.

Well, SUN has the Pass-The-Buck algorithm for solving the Repeat Offender
Problem...


I am kind of leaning toward something simple, like this:


- Deferred Reclamation

or

- Deferred Object Reclamation

or

- Deferred Concurrent Object Reclamation


> I'd be tempted to think along the lines of 'rug-maintenance' since what
> happens when you free something too soon is that the rug gets pulled
> out from under the other threads...

:)


Joe Seigh

unread,
Jul 11, 2006, 8:46:35 PM7/11/06
to
Chris Thomasson wrote:
> <gottlo...@gmail.com> wrote in message
> news:1152637280.7...@m79g2000cwm.googlegroups.com...
>
>>'free-handing' would be a boring term, without much context (could
>>instead say 'thread-safe free handling' but it is a bit long). Also
>>not much different than GC, but it does sound more low-level.
>
>
> Well, SUN has the Pass-The-Buck algorithm for solving the Repeat Offender
> Problem...
>
>
> I am kind of leaning toward something simple, like this:
>
>
> - Deferred Reclamation
>
> or
>
> - Deferred Object Reclamation
>
> or
>
> - Deferred Concurrent Object Reclamation
>

Too much like MP Defer which as the original name in
VM/XA. :)

Refcounting would have to fit under this terminology
too.

gottlo...@gmail.com

unread,
Jul 12, 2006, 12:56:54 PM7/12/06
to

Chris Thomasson wrote:
> >
> > Joe Seigh wrote:
> >> I've been using the term GC (garbage collection) to cover
> >> things like RCU, SMR hazard pointers, and possibly reference
> >> counting. The problem is there are too many people who think
> >> GC only means Boehm style tracing and are clue impervious to
> >> other possibilities which makes any discussion on GC rather
> >> skewed and lop sided.
> >>
> >> Any ideas? You'd get to invent a new term for compsci.
> >>
> I am kind of leaning toward something simple, like this:
>
>
> - Deferred Reclamation
>

I like that term, but is it just one technique to handle the problem,
or does it describe the problem? Is deferring the only way? Maybe
sometimes you *can* delete right away. Maybe someday we'll think of
something else completely?...

Tony

Joe Seigh

unread,
Jul 12, 2006, 6:16:30 PM7/12/06
to

It sort of describes the solution. In a lot lock-free algorithms there
a section in the logic that goes "wait until no other threads are referencing
this object and then do something". So a synonym for wait in there. Maybe
something to do with references or access to the object. And remember all
these lock-free algorithms work with different forms of this scheme. So
for lock-free reference counting you can use RCU, or you can use SMR, or
you can use regular GC, etc...

gottlo...@gmail.com

unread,
Jul 12, 2006, 9:35:19 PM7/12/06
to

Joe Seigh wrote:

> gottlo...@gmail.com wrote:
> >>
> >>- Deferred Reclamation
> >>
> > I like that term, but is it just one technique to handle the problem,
> > or does it describe the problem? Is deferring the only way? Maybe
> > sometimes you *can* delete right away. Maybe someday we'll think of
> > something else completely?...
> >
>
> It sort of describes the solution. In a lot lock-free algorithms there
> a section in the logic that goes "wait until no other threads are referencing
> this object and then do something". So a synonym for wait in there. Maybe
> something to do with references or access to the object. And remember all
> these lock-free algorithms work with different forms of this scheme. So
> for lock-free reference counting you can use RCU, or you can use SMR, or
> you can use regular GC, etc...
>

Yeah, it was sort of a rhetorical question (or a few). I was just
trying to make sure the term was general enough to cover all solutions
(ie by concentrating on the problem instead). But I can't imagine a
solution that does NOT involve 'deferring', so maybe that term is good
enough...

Tony

Joe Seigh

unread,
Jul 22, 2006, 11:30:08 AM7/22/06
to
Chris Thomasson wrote:
>
>
> I am kind of leaning toward something simple, like this:
>
>
> - Deferred Reclamation
>
> or
>
> - Deferred Object Reclamation
>
> or
>
> - Deferred Concurrent Object Reclamation
>
>
>
>

Well, PCOW (partial copy on write) describes the general
read lock-free technique so we could call this
PCOW deferred reclamation or PDR for short.

Chris

unread,
Jul 28, 2006, 8:00:01 AM7/28/06
to
How about Shared Memory Access and Reclaim Technologies?

Steve Watt

unread,
Jul 28, 2006, 7:32:19 PM7/28/06
to
In article <1154088001....@s13g2000cwa.googlegroups.com>,

Chris <ch...@chrisbird.com> wrote:
>How about Shared Memory Access and Reclaim Technologies?

You're just being smart.

:)

Data Lifetime Management?

That sounds like a database thing, though...
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3"
Internet: steve @ Watt.COM Whois: SW32-ARIN
Free time? There's no such thing. It just comes in varying prices...

Reply all
Reply to author
Forward
0 new messages