Python vs Java garbage collection?

[Stuart D. Gathman]

On Mon, 23 Dec 2002 12:08:54 -0500, Martin v. Löwis wrote:

>> In C++, using an auto_ptr example, the instant an object's reference
>> count goes to 0 it's destructor will be called.
> 
> That is certainly also true.
> 
> However, I'm still curious as to what precisely the '"destructors
> please" issue' is that you have been pushing for quite some time, and
> what precisely it would mean to add destructors to Python and Java. I'm
> speaking as a language designer here, so I'm not too interested in how
> you would use the facility until I know what the facility is.

What is desired is the equivalent of try...finally.  It seems that
try...finally is cluttered enough that programmers avoid it whenever they
deem it unnecessary to enhance readability.

This idiom:

   try:
 	fp = open(...)
	do_something()
   finally:
	fp.close()

is what we want to enhance to meet the following objectives:

  a) programmers won't avoid proper finalization because of readability

  b) programmers would find that proper finalization so convenient, that
they use it all the time even when not required - so that a library can
add a finalization requirement (e.g. close() method) and reasonably
expect most clients not to break.

One feature is a given:  there must be a way to identify objects
requiring finalization at their definition - *not* at their point of use.
 In Java, the obvious thing is to define an interface (e.g. Disposable)
with a close() or dispose() method.  In Python, a base class for python
classes or type flag for C objects would do the trick.

Secondly, Java and Python will not have the problem of C++ with the
danger of references causing undefined behaviour after an object is
disposed.  Trying to do things with a disposed object is just as well
defined as trying to do things with a closed file.  A well designed
object will probably throw an exception - or possibly do nothing - but it
is well defined and up to the programmer.

Now, the tricky part is that these Disposable objects might go into
containers, so we can't simply declare that they are disposed when the
block where they are created ends.  I.e., the following would be
convenient only for certain (common) situations:

def myfunc():
  fp = open(...)	# assume file is "Disposable"
  so_something()
  # fp is closed at block exit

Furthermore, any object which contains a disposable object should itself
be disposable, and so on.

Thinking about this eventually leads to the conclusion that reference
counting is the easiest way to define the desired semantics.  The most
telling evidence of this is that Java uses reference counting to handle
external resources in systems like RMI and JINI.  This is implemented by
creating proxy objects which in turn manage reference counts.

One way to make this more efficient as a language extension is to have
the virtual machine maintain mandatory reference counts for Disposable objects -
but continue to use implementation defined GC for normal objects.  The
language would then guarantee a call to the dispose() method when the
reference count reaches 0.  Calling dispose() would *not* release memory
or cause undefined behaviour.

-- 
	      Stuart D. Gathman <stuart at bmsi.com>
Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.