On 28.04.2015 21:22, Bert Huijben wrote: > >> -----Original Message----- >> From: Marc Strapetz [mailto:marc.strap...@syntevo.com] >> Sent: dinsdag 28 april 2015 20:26 >> To: Branko Čibej >> Cc: Subversion Development >> Subject: Re: 1.9 JavaHL memory leak in ISVNRemote#status >> Also, I should add that according to the Profiler, the byte[]s are >> referenced from the Checksums. The char[]s are referenced from the >> Strings. And the Strings are referenced directly as JNI local >> references. Browsing through these Strings, they seem to be server-side >> paths ("subversion/branches/1.8.x/...") > Just guessing: Notifications?
No, this is an RA status edit drive; there are no notifications, only editor callbacks, and the checksum objects are created in in the callbacks related to file content changes (file contents streams and checksums always come in pairs). I counted creations, finalizations and garbage collections again. I added forced finalization and GC calls to the test case. For every loop in the test, we create 57 Checksum instances, but only one of them is finalized, no matter how often the finalizer and GC are run. All the Checksum objects are created in the same way, and here are /no/ references anywhere to the remaining 56 objects, yet they're neither finalized nor garbage-collected. The fields (byte array and kind) /are/ collected; all the "live" (according to the heap profiler) Checksum objects have their fields set to null. I'm going to write this off as an implementation detail of the Java garbage collector; clearly, the code is cleaning up the references correctly, but for some unfathomable reason, the collector keeps them alive for a while. Maybe this will behave differently in a real application than in this limited test case. -- Brane