Python vs Java garbage collection?

[Beni Cherniavsky]

On 2003-01-08, holger krekel wrote:

> Beni Cherniavsky wrote:
> > On 2003-01-06, holger krekel wrote:
> >
> > > Beni Cherniavsky wrote:
> > > > I think this is a technical question: is it possible in CPython and Jython
> > > > to mutate an existing object's class, to mark it as dead?If yes, then a
> > > > facility to explicitly force a __del__ if any (and fry the object so it
> > > > can't be used any more) would be a solution for writing portable code:
> > > >
> > > > x = acquire()
> > > > try:
> > > >     do_something(x)
> > > > finally:
> > > >     finalize(x)
> > >
> > > why is this better than the traditional e.g.
> > >
> > > lock.acquire()
> > > try:
> > >     do_critical_work()
> > > finally:
> > >     lock.release()
> > >
> > Err, emmm, aah, Good Question. :-)
> >
> > More seriously, it allows one to always call the destructor __del__
> > without knowing in advance whether the user will be happy with relying on
> > automatic finalization or will destroy it excplicitly.In particular,
> > suppose I write a module and it relies on __del__; now somebody wants to
> > use it in Jython and/or in some context I didn't envision that requires
> > explicit finalization at some predictable time.Currently, he has no way
> > short of changin my module and redesigning the interface.I don't think
> > there is currently a good way to "fry" an object before its time from pure
> > Python, so calling __del__ manually is problematic.
>
> Right, this is problematic.
>
> Regarding your module, If you have something like:
>
>   def f():
>       data = open(source).read()
>
> then it is hard to finalize thefile from the outside.
> We don't even have a name to refer to.
>
True.  I'm not sure to what you are relating from what I said.

> > Also, since I never saw a resources that can be destroyed in more than one
> > way <wink>, it makes some sense to have a single name agreed name for it.
> > Sometimes, it could allow writing generic code that releases a resource
> > without knowing what it is exactly.For example, in a related thread some
> > time ago I proposed that the for loop should finalize the iterator (with
> > finally-like guarantee.
>
> Hmmm.Care to give a concrete example?
>
The idea had to do with allowing yield in try..finally (there are various
reasons to want that).  Now, a generator is quite helpless, once it
yields, so the finally clasuse can't be guaranteed to execute completely.
It can be guaranteed on __del__ but than the code relying on it would
usually be no good in Jython.  This makes promising it to be run on
__del__ a bad design decision for Python (notice that currently you can
choose to depend on ref-counting or not but nothing else in the language
design assumes that you can; otherwise the Jython implementors would have
a hard time following).  Therefore idea was that generators should have a
finalization method to be called, at least in Jython, in predictable
places.  In particular, since the for loop doesn't expose the iterator it
creates, the loop itself should be responsible for calling this method.
As Isaid that would break when you already pass an iterator, so the idea
doesn't work out.

> > In CPython, it already happens (__del__ is called) and in Jython this
> > would need to be coded.  It can't quite work that way because people
> > sometimes give pre-existing iterators to for, expecting them to remain
> > alive.  Still, it shows the idea: an API that creates user objects
> > without exposing it, has known lifetime for the object but gives the
> > user no way to finilize explicitly, so it makes very much sense for
> > the API to guarantee this finilization.Currently you cannot implement
> > such a guarantee under Jython; with the added builtin, you can.
>
> I am not so sure how (and why) something like a 'finalize' builtin could be
> made to work.

By calling __del__ if, breaking any poionters in the objects to other
objects and directly changing the type pointer (or whatever Jython has) to
some "FriedObejctType".  I'm not sure that it's technically feasible,
though, especially on Jython.

> I don't have the situation often where i don't know how to finalize a
> resource.
>
The intended situatuin is when you do know how the resource should be
finilized - by deallocation, hence invoking __del__ - but you can't use
that route because you it done *now* and run on Jython.  The idea is to
allow code to rely on __del__, without making it useless on Jython.  Also
it allows to amend an API that originally was happy with implicit
fininaliztion but suddenly needs timely predicatable finalization in some
specific cases, with minimal pain (without having to choose some name
different from __del__).

Of course all this depends on whether such "frying" of objects before
their time is possible.

-- 
Beni Cherniavsky <cben at tx.technion.ac.il>