On 2015-05-02 23:06, Cecil Westerhof wrote:
> Op Saturday 2 May 2015 22:17 CEST schreef Tim Chase:
>> This creates a cycle, then makes it unreachable, but the list is
>> still referenced by itself, so the reference count never drops to
>> zero (where it would get GC'd), and thus that item lingers around
>> in memory.
>
> Maybe look at Java? If my memory is correct, the JVM gc reclaims
> those kind of things also.
The two most common ways of doing garbage collection are
reference-counting and mark-and-sweep. They're not mutually
exclusive, and can be combined, but each has advantages to counter
disadvantages of the other. In reference-counting, you have the
overhead of incrementing/decrementing a counter and the
above-mentioned unreachability issue. With mark-and-sweep, you can
end up with pauses as the VM rejiggers memory.
It's also my understanding that Jython uses the JVM and thus gets the
JVM's generational mark-and-sweep memory management instead of the
reference-counting that the CPython implementation does. The GC
technique isn't part of the Python spec (AFAIK), so it's up to the
individual implementation which one to use. MRAB's post-with-link
regarding CPython's implementation suggests that CPython does
indeed provide optional mark-and-sweep style collection:
"""
CPython implementation detail: CPython currently uses a
reference-counting scheme with (optional) delayed detection
of cyclically linked garbage, which collects most objects as
soon as they become unreachable, but is not guaranteed to
collect garbage containing circular references. See the
documentation of the gc module for information on controlling
the collection of cyclic garbage. Other implementations act
differently and CPython may change. Do not depend on
immediate finalization of objects when they become
unreachable (so you should always close files explicitly).
"""
So it sounds like you have to request such a mark-and-sweep from
the gc module.
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
