Issue1960

classification
Title: sys missing 'getrefcount'
Type: behaviour Severity: normal
Components: Core Versions: 2.5.3b2, 2.7a2
process
Status: closed Resolution: invalid
Dependencies: Superseder:
Assigned To: amak Nosy List: adorsk, amak
Priority: Keywords:

Created on 2012-08-18.17:05:58 by adorsk, last changed 2012-08-28.19:01:28 by amak.

Messages
msg7413 (view) Author: Alex the Jython User (adorsk) Date: 2012-08-18.17:05:57
The 'sys' module appears to be missing the 'getrefcount' method.

==== Example ====

=== code ===
import sys
a = [1,2,3]
sys.getrefcount(a)

=== result ===

AttributeError: '<reflected field public org.python.core.PyObject o' object has no attribute 'getrefcount'
msg7424 (view) Author: Alan Kennedy (amak) Date: 2012-08-25.21:05:40
sys.getrefcount is not meaningful on jython, only on cpython.

cpython uses reference-counting for garbage collection. Read more here

http://en.wikipedia.org/wiki/Reference_counting

Jython, because it runs on Java Virtual Machines, uses Java Garbage Collection, which may use one of several different garbage collection mechanisms, mostly much more sophisticated than relatively basic ref-counting algorithms. Read more here

http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

So basically sys.getrefcount would have no meaning on java/jython, and there is no way to implement it.

I'm going to close this bug as "invalid".

If you think that you need to use the sys.getrefcount method, please send an email, describing your use-case, to the jython-users mailing list.
msg7430 (view) Author: Alex the Jython User (adorsk) Date: 2012-08-28.12:14:57
Roger that, thanks for the detailed explanation.

I had submitted this bug because some of the SQLAlchemy test cases use getrefcount.  But based on your explanation it sounds like it makes more sense to modify the SQLAlchemy code instead to check for whether it's running in a jython environment.

No need for any further action on this.  Thanks in general for the great work on Jython.
msg7434 (view) Author: Alan Kennedy (amak) Date: 2012-08-28.19:01:28
> "I had submitted this bug because some of the SQLAlchemy test cases use getrefcount."

OK.

That could give rise to problems.

The "problem" with cpythons refcounting GC is that it gives very precise guarantees about when an object is destroyed, i.e. when its __del__ method is called.

It is not possible to support these guarantees on jython, given the nature of Java GC.

Consider the following code, run on both python and jython.

C:\>python
Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class o:
...     def __init__(self):
...         print "Hello"
...     def __del__(self):
...         print "Goodbye"
...
>>> my_o = o()
Hello
>>> del my_o
Goodbye
>>> ^Z
C:\>

C:\>jython
Jython 2.7a0+ (, Mar 31 2012, 21:43:20)
[Java HotSpot(TM) Client VM (Sun Microsystems Inc.)] on java1.6.0_29
Type "help", "copyright", "credits" or "license" for more information.
>>> class o:
...     def __init__(self):
...         print "Hello"
...     def __del__(self):
...         print "Goodbye"
...
>>> my_o = o()
Hello
>>> del my_o
>>>^D
C:\>

Note that the __del__ method may not even be run on jython.

This may not be a problem for you in your work with SQLAlchemy. But I thought it worth pointing it out.

And it is arguable that cpython code that depends on the object-lifecycle guarantees cpython's refcounting GC is not portable.

For example, pypy has a wide range of GC options available, where the cpython guarantees will not hold.

http://doc.pypy.org/en/latest/garbage_collection.html
History
Date User Action Args
2012-08-28 19:01:28amaksetmessages: + msg7434
2012-08-28 12:14:57adorsksetmessages: + msg7430
2012-08-25 21:05:42amaksetstatus: open -> closed
assignee: amak
resolution: invalid
messages: + msg7424
nosy: + amak
2012-08-18 17:05:58adorskcreate