On 28.04.2015 21:22, Bert Huijben wrote:
>
>> -----Original Message-----
>> From: Marc Strapetz [mailto:marc.strapetz_at_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
Received on 2015-04-29 05:32:23 CEST