[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Subclipse-users] No dispose() on SVNClients in Subclipse?

From: Mark Phippard <mphippard_at_collab.net>
Date: Mon, 5 Jan 2009 10:26:22 -0500

On Thu, Dec 25, 2008 at 5:39 AM, Victor Antonovich <victor_at_mobileap.ru> wrote:

> I'm using Subclipse 1.4.7 with SVNKit backend under Eclipse 3.4.1
> running Fedora 10 OS. After some intensive SVN operations like
> committing and branching Eclipse heap usage raises to some hundred
> megabytes. Doing heap dump analysis using Eclipse Memory Analysing Tool
> (MAT) some suspicions of memory leak were discovered. Below is MAT Leak
> Suspect Report:
>> The class "org.tmatesoft.svn.core.javahl.SVNClientImplTracker",
>> loaded by "org.tmatesoft.svnkit", occupies 276 222 104 (67,28%)
>> bytes. The memory is accumulated in one instance of
>> "org.tmatesoft.svn.core.internal.util.SVNHashMap$TableEntry[]" loaded
>> by "org.tmatesoft.svnkit".
> Looking quickly through Subclipse code, seems like SVNClients are
> created but not disposed via dispose() method, so memory leak can be
> caused. Is my suspicion right or not?

You are correct we do not call the dispose() method and do not really
have any way to do so. In the 1.4.x releases we changed the
architecture significantly to workaround this. Specifically, for
JavaHL we only create a single object and then we use it
multi-threaded. This does not work for SVNKit because it is not
threadsafe. So we had to resort to the old pre-1.4.x behavior of
constructing a new object for each usage.

Perhaps someone can come up with a patch so that dispose is called
when/if the object is garbage collected, but I'd assume that SVNKit
already does that to the degree it is possible. We do not have any
way in Subclipse to know when we can dispose the client object.

Mark Phippard
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2009-01-05 16:26:41 CET

This is an archived mail posted to the Subclipse Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.