Python vs Java garbage collection?

["Martin v. Löwis"]

Martin Maney wrote:
> Yes, I assumed that that was at least a good part of the reason Jython
> abandonded the traditional ref counting of CPython.  This was also
> meant to be implicit agreement with your perhaps rhetorical question to
> the previous poster.  

It was 50% rhetorical, as I'm convinced there is no satisfying answer; I 
  assumed a 50% chance that Bengt tries to answer (and was surprised 
that somebody else answered).

> Now that would be a problem.  I'm not familiar with Jython, so I have
> no idea how common that sort of use is, or whether restricting
> "guaranteed to finalize like classic CPython objects" objects from
> being so referenced would be feasible.  

It is often concidered as a strength of Jython that you can integrate so 
easily with the Java library; this may involve call-backs from Java to 
Python, which in turn requires that "pure" Java object hold references 
to Python objects. A common example for that is usage of the AWT or 
Swing in Jython.

> My impression, which may be
> incomplete or even just wrong, is that Jython's motivation was mostly
> to allow a Python language implementation that ran on top of the Java
> VM, and which could access the Java libraries.

Just *having* that implementation is not enough motivation, people also 
want to *use* it. Although they have to suffer a few limitations due to 
absent modules, they can overcome these limitations in many cases by 
using the Java library. Code that runs both on CPython and Jython often 
has try-except-ImportError blocks to chose either the C or the Java 
version of some functionality. Where possible, Jython wraps the API, but 
for more complex APIs (GUI, XML), this is not feasible.

> If they can compile Lisp into machine code, why not Python?  

Feel free to try, and to make any changes to the language that you feel 
necessary. As you proceed, you will either
a) find that your entire approach is doomed and give up, or
b) find that you have to make so many changes to the language that
    nobody is interested in using your code, or
c) find that some of the language changes that you initially had to make
    can be taken back without loss of generality or performance.

If you arrive at alternative (c), feel free to discuss any remaining 
language changes with other Python authors. There is no need for a 
proactive change to accomodate an imaginary implementation. The 
often-cited statement in the language reference with regard to 
refcounting came precisely out of the Jython development, and is there 
to support Jython only.

I believe Mark Hammond's Python .NET ended up in alternative (b) (or 
(a), depending on your point of view). Apart from that, I'm not aware of 
any prospective alternative Python implementations that have troubles 
with the refcounting.

> So I am extrapolating from past experiences with using ref counting
> in other contexts to an assumption that Python's implementation might
> be able to choose an answer other than "all" or "nothing".

Can you please explain how these schemes work? In CPython, all objects 
are of type PyObject*, and Py_INCREF and Py_DECREF are macros that 
access the internal structure of a PyObject, which contains the member 
ob_refcount.

> May I reflect an altered version of this back to you?  Under the
> hypothesis that CPython changed so that not all objects were reference
> counted, how many places in the VM would need to distinguish between
> ref-counted and non-rc objects?  

You find a Py_INCREF macro invocation about every three lines of CPython 
module source code, not only for core modules, but also for every 
extension module out there.

> Would it be easier to have the
> distinction made based on the object's type or at a lower level such as
> a sentinel ref count value?

Both would work, I guess, but both would also slow down CPython, as you 
now have to look into the type / for the sentinel value before modifying 
the refcount.

This doesn't translate to Jython at all, since Jython uses native VM 
instructions and the native VM stack to manipulate object references, be 
it references to Jython objects, or to "pure" Java objects.

Regards,
Martin