[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: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 24 Apr 2015 09:39:02 +0100

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.

Thanks, Brane. While there is clearly some interesting longer term
work to do, and while I don't completely follow all the details, that
helps understand the current situation.

- Julian
Received on 2015-04-24 10:43:16 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.