garbage collection / cyclic references

[Aaron Brady]

On Mar 21, 11:59 am, "andrew cooke" <and... at acooke.org> wrote:
> Aaron Brady wrote:
> > My point is, that garbage collection is able to detect when there are
> > no program-reachable references to an object.  Why not notify the
> > programmer (the programmer's objects) when that happens?  If the
> > object does still have other unreachable references, s/he should be
> > informed of that too.
>
> i think we're mixing python-specific and more general / java details, but,
> as far as i understand things, state of the art (and particularly
> generational) garbage collectors don't guarantee that objects will ever be
> reclaimed.  this is a trade for efficiency, and it's a trade that seems to
> be worthwhile and popular.

It's at best worthless, but so is politics.  I take it back; you can
reclaim memory in large numbers with a probabilistic finalizer.  The
expected value of reclaiming a KB with a 90% chance of call is .9 KB.

The allocation structure I am writing will have a very long up-time.
I can forcibly reclaim the memory of an object involved in a cycle,
but lingering references it has will never be detected.  Though, if I
can't guarantee 100% reclamation, I'll have to be anticipating a
buffer dump eventually anyway, which makes, does it not, 90% about the
same as 99%.

> furthermore, you're mixing responsibilities for two logically separate
> ideas just because a particular implementation happens to associate them,
> which is not a good idea from a design pov.

I think a silent omission of finalization is the only alternative.  If
so they're mixed, one way or the other.  I argue it is closer to
associating your class with a hash table: they are logically separate
ideas.  Perhaps implementation is logically separate from design
altogether.

> i can remember, way back in the mists of time

I understand they were having a fog problem there yesterday... not to
mention a sale on sand.  "Today: Scattered showers and thunderstorms
before 1pm, then a slight chance of showers."

> using java finalizers for
> doing this kind of thing.  and then learning that it was a bad idea.  once
> i got over the initial frustration, it really hasn't been a problem.  i
> haven't met a situation

I don't suppose I imagine one.  So, you could argue that it's a low
priority.  Washing your hands of the rare, though, disqualifies you
from the associate's in philosophy.  I bet you want to meet my
customers, too.

> where i needed to tie resource management and
> memory management together (except for interfacing with c code that does
> not use the host language's gc - and i can imagine that for python this is
> a very strong (perhaps *the*) argument for reference counting).

I'm using a specialized mapping type to implement the back end of user-
defined classes.  Since I know the implementation, which in particular
maps strings to objects, I can always just break cycles by hand; that
is, until someone wants a C extension.  Then they will want tp_clear
and tp_traverse methods.

> as an bonus example, consider object caching - a very common technique
> that immediately breaks anything that associates other resources with
> memory use.

I assume your other processes are notified of the cache state.  From
what I understand, Windows supports /named/ caching.  Collaborators
can check the named cache, in the process creating it if it doesn't
exist, and read and write at will there.

> just because, in one limited case, you can do something, doesn't mean it's
> a good idea.
>
> andrew

But you're right.  I haven't talked this over much on the outside, so
I might be missing something huge, and serialized two-step
finalization (tm) is the secret least of my worries.