Re: finalizers depend on Java import

>It can't be assumed that garbage collection runs at any particular time: even the call to gc is only a suggestion.

I used the following code to run GC, which would cause the test to hang unless GC really runs:

class GCDetector():

gcIndex = 0

def __del__(self):

GCDetector.gcIndex += 1

def runGCIfJython():

if platform.system() == "Java":

currentIndex = GCDetector.gcIndex

detector = GCDetector()

detector = None

while currentIndex == GCDetector.gcIndex:

System.gc()

time.sleep(0.1) #Also tried this with vastly sufficient wait-times, up to 10s

I think this proves that GC-request is actually served (if the test doesn't hang; and it doesn't). http://stackoverflow.com/questions/2135089/can-any-unused-object-escape-from-garbage-collector states that iff GC runs, all unreferenced objects are deleted, which proves that A is still referenced for no obvious reason, although it was set to None. I admit this argument is for Java and Jython sometimes behaves different than Java. I assumed (wrongly it seems) A = None would guarantee one less reference to A at once.

I don't care, if Jython somehow keeps an internal reference slightly longer than needed, given that it is no permanent memory leak. It first appeared to me that only a subsequent import would release this - an event that is not guaranteed to happen.

That said, I recently observed that a subsequent gc run collects A, iff this run occurs outside the current method (counting calls to other methods as "inside", which is why this does not work in test_clear_object_surround_java_import_3), i.e. in the next test. Given that the method-end also releases the keep-alive rather than only another import, I would consider it as okay (still not perfect - imagine this would happen in the main method...). Sorry that I did not find this earlier.

Stefan

Gesendet: Dienstag, 19. August 2014 um 00:41 Uhr

Von: "Jeff Allen" <[email protected]>

An: [email protected]

Betreff: Re: [Jython-dev] finalizers depend on Java import

It can't be assumed that garbage collection runs at any particular time: even the call to gc is only a suggestion. Many CPython tests assume objects are destroyed when they pass out of scope, but they have to be modified or skipped in Jython. Occasionally we really need GC to run, but it seems you have to go to extraordinary lengths. See: http://hg.python.org/jython/file/83cd10f1826d/Lib/test/test_weakref.py#l10

What you observe is odd, but it's not actually incorrect, is it?

Jeff Allen

On 18/08/2014 22:27, Stefan Richthofer wrote:

I did more experiments and created a unit test for this phenomenon. If nobody can explain this behavior, I would consider it a memory leak and file a bug.

Let me comprehend my observations:

An import between A = SomeClass() and A = None causes A to be kept alive for some reason, if gc runs after that.

Interestingly it appears that another import after A = None releases this alive-keeping (see test_clear_object_surround_java_import_2 in the attached file), unless this subsequent import happens in another method (test_clear_object_surround_java_import_3).

It seems to make no difference, whether the imports are Java or Python imports.

I know this is probably of rare interest, since it is a really strange scenario to perform imports at such places. However, I find this behavior strange enough to indicate that something is not sufficiently understood/something is not working cleanly. Since I am currently fixing finalizer issues and don't want to overlook something, I would prefer to understand this despite the maybe rare common interest. Somehow the import process establishes a strong reference to A, keeping it alive. I suspect it might be hard to find out how this happens. So if someone more familiar with Jython's import process could point me somewhere, this would be helpful.

Stefan

------------------------------------------------------------------------------ _______________________________________________ Jython-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jython-dev

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

_______________________________________________
Jython-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jython-dev