[Jython-bugs] [ jython-Patches-1634167 ] PyInstance/PyFinalizable do not work with acquired __del__

[SourceForge.net <no...@so...>]

Patches item #1634167, was opened at 2007-01-12 11:08
Message generated for change (Settings changed) made by cgroves
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312867&aid=1634167&group_id=12867

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: leouser (leouserz)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyInstance/PyFinalizable do not work with acquired __del__

Initial Comment:
__del__ does not appear to work correctly if acquired in jython.  This py script works fine on Python 2.5:


class z:
   pass

a = z()
def __del__(a):
    print "DEL"
z.__del__ = __del__
a = None

x = z()
x = None

print dir(z)

class z:
    def __del__(a):
        print "DEL2"
f = z()
f = None

import sys
if(len(sys.argv) > 1):
    import java
    java.lang.System.gc()
    java.lang.Thread.sleep(5000)


z always has its __del__ called even if acquired.  In jython this appears not to work for classes that acquire __del__.  Im not sure of the cause, but I would expect the instance created after acquiring __del__ to fire "DEL" off.  I believe the problem for the second case is because PyClass does not mutate when __del__ is added to it.  Well it mutates but it doesn't appear to reset an internal variable that determines if the new PyInstance will be finalizable or not.  Additionally it appears that PyType defines a variable that is not used: "needs_finalizable".  PyClass looks for __del__ being set not "needs_finalizable".

Now for existing classes this poses a problem.  If __del__ is defined at instantiation time it is a PyFinalizableInstance that is created.  The documentation states that PyFinalizableInstance exists because of performance problems.  It would be good to see what these are.  The only solution I can think of at this moment is to remove PyFinalizableInstance and just make PyInstance with a finalize method.  It could then check on finalize if __del__ exists and do its work.




----------------------------------------------------------------------

Comment By: leouser (leouserz)
Date: 2007-01-12 13:07

Message:
Logged In: YES 
user_id=1277399
Originator: YES

There may be more mutation problems beyond __del__:
    // Store these methods for performance optimization

    // These are only used by PyInstance

    PyObject __getattr__, __setattr__, __delattr__, __tojava__, __del__,

            __contains__;


from "PyClass".  If these are mutated I don't see any corresponding change
code in the PyClass instance that will reset these fields.

----------------------

A possible different solution to the mutating __del__ problem is to use a
variation on the FinalizerGuardian from Effective Java.
1. Keep track of all PyInstances created by the PyClass
2. If __del__ is altered iterate the PyInstances and add/delete a
FinalizerGuardian whose responsibility is to __del__ the PyInstance when
itself is finalised.

This is good in that it makes the PyInstance finalizability changable on
the fly.  Its bad because its going to add alot of references to the system
and a special object for finalising.



----------------------------------------------------------------------

Comment By: leouser (leouserz)
Date: 2007-01-12 12:05

Message:
Logged In: YES 
user_id=1277399
Originator: YES

A possible fix for the __del__ added after the class is defined is the
patch attached.  If an instance is created after this it will be able to
create a PyFinalizableInstance.  Now this patch in itself seem problematic.
 PyFinalizableInstance doesn't check if its __del__ method has been nulled
out.  But this doesn't appear to cause any terrible problems at finalize
time.  It still would be better to check things out and not throw a
NullPointerException(this appears hidden).

The simplest fix would be to define finalize in PyInstance and check if
__del__ is not null in its instclass variable.  If so, execute __del__. 
This would probably take care of any problems with mutations on __del__ for
all existing instances.  Though I am worried about PyInstances sitting in
memory longer than they need to.


File Added: PyClassDiff.txt

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312867&aid=1634167&group_id=12867