To GC or not to GC? 
Author Message
 To GC or not to GC?

OK, newbie here, recently reassured that python now comes with
generational GC that can handle cyclic refs of otherwise unreachable stuff.

But the doc: http://www.*-*-*.com/

...says "(Implementation note: the current implementation uses a
reference-counting scheme with (optional) delayed detection of cyclicly
linked garbage, which collects most objects as soon as they become
unreachable, but is not guaranteed to collect garbage containing
circular references. See the Python Library Reference for information on
controlling the collection of cyclic garbage.)"

following that link I see: "This [GC] module provides an interface to
the optional garbage collector. ... It also provides access to
unreachable objects that the collector found but cannot free. Since the
collector supplements the reference counting already used in Python, you
can disable the collector if you are sure your program does not create
reference cycles."

My questions are:

1. Is that doc up to date? I see Mar 2002, not too shabby.

2. Well, I should almost wait before asking further, but if you'll
forgive a little lookahead, that "supplements reference counting" scares
me. Is ref counting history or not? mind you, i understand there is a
lot of code out there taht must be supported, but for new code...?

TIA...

--

  kenny tilton
  clinisys, inc
  ---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
   and I'm happy to state I finally won out over it.""
                                                   Elwood P. Dowd



Tue, 10 May 2005 04:49:55 GMT  
 To GC or not to GC?

Quote:

> 1. Is that doc up to date? I see Mar 2002, not too shabby.

Yes.

Quote:
> 2. Well, I should almost wait before asking further, but if you'll
> forgive a little lookahead, that "supplements reference counting"
> scares me. Is ref counting history or not? mind you, i understand
> there is a lot of code out there taht must be supported, but for new
> code...?

What do you mean, "for new code"? The reference counting is still
done, for all code. There is no reasonable way to disable it for some
code but leave it active for other code.

There is also nothing wrong with reference counting. If the reference
counter drops to zero, the object is gone before the cyclic garbage
collector is even invoked.

Furthermore, the cyclic GC *relies* upon refcounting. It does not,
itself, collect any memory. Instead, it picks an arbitrary object from
the cycle and asks to clear itself, i.e. to drop all references it may
have to other objects. That breaks the cycle in a single place, and
causes refcounting to unwind all objects in the cycle.

Regards,
Martin



Tue, 10 May 2005 05:00:14 GMT  
 To GC or not to GC?

Quote:


>>1. Is that doc up to date? I see Mar 2002, not too shabby.

> Yes.

>>2. Well, I should almost wait before asking further, but if you'll
>>forgive a little lookahead, that "supplements reference counting"
>>scares me. Is ref counting history or not? mind you, i understand
>>there is a lot of code out there taht must be supported, but for new
>>code...?

> What do you mean, "for new code"? The reference counting is still
> done, for all code. There is no reasonable way to disable it for some
> code but leave it active for other code.

Sorry, I looked at Python years ago and thought I saw /manual/ ref
counting, but maybe that was just the stuff done by C code (which I
understand is ineluctable).

--

  kenny tilton
  clinisys, inc
  ---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
   and I'm happy to state I finally won out over it.""
                                                   Elwood P. Dowd



Tue, 10 May 2005 06:29:06 GMT  
 To GC or not to GC?

Quote:

> Sorry, I looked at Python years ago and thought I saw /manual/ ref
> counting, but maybe that was just the stuff done by C code (which I
> understand is ineluctable).

Ah, yes. Refcounting in C code is still required from extension
writers; all alternatives to it would also require cooperation from
extension writers in some way.

There was never a need to do explicit refcounting in Python source
code.

Regards,
Martin



Tue, 10 May 2005 07:36:08 GMT  
 To GC or not to GC?

Quote:

> Sorry, I looked at Python years ago and thought I saw /manual/ ref
> counting, but maybe that was just the stuff done by C code (which I
> understand is ineluctable).

Wow, you have been taken in by the propaganda :)

Cheers,
M.

--
  Need to Know is usually an interesting UK digest of things that
  happened last week or might happen next week. [...] This week,
  nothing happened, and we don't care.
                           -- NTK Now, 2000-12-29, http://www.ntk.net/



Sun, 15 May 2005 20:21:06 GMT  
 To GC or not to GC?

Quote:

> > Sorry, I looked at Python years ago and thought I saw /manual/ ref
> > counting, but maybe that was just the stuff done by C code (which
I
> > understand is ineluctable).

Yes.  If you interact with the C Python interpreter with C code by
using the C API, you must learn about ref counting and occasionally
use incref(ob) and decref(ob).  Makes you appreciate what the
interpreter hides when we write Python code.  (It also hides numerous
system and compiler differences and incompatibilities, but that's
another story.)

TJR



Mon, 16 May 2005 02:33:47 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. GC, and objects finalization (was: GC,again)

2. GC and Aging, GC and Allocator Surveys available

3. : #() not GC'ed - bug or ??

4. GC is Not Sufficient (Re: Avoiding the second historic mistake)

5. 'conservative' GC == 'risky' GC

6. real-time & generational GC (free incremental GC, too)

7. 'conservative' GC == 'risky' GC

8. GC benchmarks and comparison (and What GC we're using now?)

9. Parallel & RT GC (was Re: Real-Time GC (was Re: Widespread C++...?)

10. Parallel & RT GC (was Re: Real-Time GC (was Re: Widespread C++...?)

11. 'conservative' GC == 'risky' GC

 

 
Powered by phpBB® Forum Software