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
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 lea
rap...@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 th
sdag 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
On 29.04.2015 05:31, Branko Čibej wrote:
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
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
On 28.04.2015 20:06, Marc Strapetz wrote:
> On 28.04.2015 18:12, Branko Čibej wrote:
>> On 28.04.2015 18:03, Marc Strapetz wrote:
>>> Hi Brane,
>>>
>>> On 28.04.2015 07:36, Branko Čibej wrote:
On 24.04.2015 14:11, Branko Čibej wrote:
>
> Hi Marc,
>
> Just a quick note: your las
> -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
On 28.04.2015 20:06, Marc Strapetz wrote:
On 28.04.2015 18:12, Branko Čibej wrote:
On 28.04.2015 18:03, Marc Strapetz wrote:
Hi Brane,
On 28.04.2015 07:36, Branko Čibej wrote:
On 24.04.2015 14:11, Branko Čibej wrote:
Hi Marc,
Just a quick note: your last msg jogged my memory and I think I
On 28.04.2015 18:12, Branko Čibej wrote:
On 28.04.2015 18:03, Marc Strapetz wrote:
Hi Brane,
On 28.04.2015 07:36, Branko Čibej wrote:
On 24.04.2015 14:11, Branko Čibej wrote:
Hi Marc,
Just a quick note: your last msg jogged my memory and I think I know
the root cause of the leak: improper J
On 28.04.2015 18:03, Marc Strapetz wrote:
> Hi Brane,
>
> On 28.04.2015 07:36, Branko Čibej wrote:
>> On 24.04.2015 14:11, Branko Čibej wrote:
>>>
>>> Hi Marc,
>>>
>>> Just a quick note: your last msg jogged my memory and I think I know
>>> the root cause of the leak: improper JNI frame management
Hi Brane,
On 28.04.2015 07:36, Branko Čibej wrote:
On 24.04.2015 14:11, Branko Čibej wrote:
Hi Marc,
Just a quick note: your last msg jogged my memory and I think I know
the root cause of the leak: improper JNI frame management within a
loop. If I'm right, I can both fix the leak and remove t
On 24.04.2015 14:11, Branko Čibej wrote:
>
> Hi Marc,
>
> Just a quick note: your last msg jogged my memory and I think I know
> the root cause of the leak: improper JNI frame management within a
> loop. If I'm right, I can both fix the leak and remove the
> close-stream requirement I just added.
>
Hi Marc,
Just a quick note: your last msg jogged my memory and I think I know the
root cause of the leak: improper JNI frame management within a loop. If I'm
right, I can both fix the leak and remove the close-stream requirement I
just added.
On 24 Apr 2015 11:00 am, "Marc Strapetz" wrote:
> On
On 24.04.2015 06:34, Branko Čibej wrote:
On 22.03.2015 05:06, Branko Čibej wrote:
On 21.03.2015 16:23, Branko Čibej wrote:
On 19.03.2015 11:43, Marc Strapetz wrote:
Attached example performs an endless series of remote status against
the Subversion repository. When invoked with -Xmx24M, the VM
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 doi
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 cl
On 24.04.2015 09:56, Julian Foad wrote:
> Hi Brane.
>
> I'm sure you would have first looked for ways to make this happen
> automatically or not be needed. Is there anything you can report on
> that front, for future reference?
You mean, apart from in the log message?
The root of the "problem" li
Hi Brane.
I'm sure you would have first looked for ways to make this happen
automatically or not be needed. Is there anything you can report on
that front, for future reference?
- Julian
Branko Čibej wrote:
> I have to say this was one of the more "interesting" bug-hunts in my not
> entirely bor
On 22.03.2015 05:06, Branko Čibej wrote:
> On 21.03.2015 16:23, Branko Čibej wrote:
>> On 19.03.2015 11:43, Marc Strapetz wrote:
>>> Attached example performs an endless series of remote status against
>>> the Subversion repository. When invoked with -Xmx24M, the VM will run
>>> out of memory soon.
On 21.03.2015 16:23, Branko Čibej wrote:
> On 19.03.2015 11:43, Marc Strapetz wrote:
>> Attached example performs an endless series of remote status against
>> the Subversion repository. When invoked with -Xmx24M, the VM will run
>> out of memory soon. Monitoring with jvisualvm shows that the used
On 19.03.2015 11:43, Marc Strapetz wrote:
> Attached example performs an endless series of remote status against
> the Subversion repository. When invoked with -Xmx24M, the VM will run
> out of memory soon. Monitoring with jvisualvm shows that the used heap
> size constantly grows. Monitoring with
On 19.03.2015 11:43, Marc Strapetz wrote:
> Attached example performs an endless series of remote status against
> the Subversion repository. When invoked with -Xmx24M, the VM will run
> out of memory soon. Monitoring with jvisualvm shows that the used heap
> size constantly grows. Monitoring with
Attached example performs an endless series of remote status against the
Subversion repository. When invoked with -Xmx24M, the VM will run out of
memory soon. Monitoring with jvisualvm shows that the used heap size
constantly grows. Monitoring with the Task Manager shows that the
allocated memo
24 matches
Mail list logo
