Re: finalizers depend on Java import

It seems definite, then, that GC will have run. I should probably have 
said it is not guaranteed that any particular object will be finalized 
when GC runs. There are schemes that only collect some objects each time.
http://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/garbage_collect.html
This article is about a particular JVM but gives a sense of why 
behaviour you didn't predict, although quite interesting, is not 
necessarily a sign something is wrong.

Jeff

On 19/08/2014 01:38, Stefan Richthofer wrote:
> >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