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

Re: 1.9 JavaHL memory leak in ISVNRemote#status

From: Branko Čibej <brane_at_wandisco.com>
Date: Fri, 24 Apr 2015 10:25:36 +0200

On 24.04.2015 10:15, Branko Čibej wrote:
> There were two options for a fix:
>
> * dispose of the object from the native code when it goes out of
> scope; or,
> * close the stream (causing an implicit disposal) from Java code.
>
> Picking the former would mean that the Java code must not close the
> stream, since doing so would result in a crash. Picking the latter
> means that forgetting to close the stream results in a memory leak.
> Faced with this dilemma, I decided that a potential memory leak with
> documented workaround is the less horrible option.
>

Of course it's clear that memory management in JavaHL needs a serious
overhaul, but this is not the time. Also, at some later date we may be
able to remove the requirement to close the stream whilst making closing
it always safe. Given the current JavaHL RA API, the only (Java) editor
implementation likely to exist for a while is the one within JavaHL
itself that's hidden under the hood of the status receiver.

-- Brane
Received on 2015-04-24 10:26:08 CEST

This is an archived mail posted to the Subversion Dev mailing list.

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