[BTRACE-52] MEmory leak while using Profiler or extra memory footprint needed ? about btrace HOT 4 CLOSED

[author="jbachorik", created="Sun, 29 Aug 2010 10:49:13 +0200"]

Yes, this is caused by a problem in the algorithm of resizing an internal profiler structure in order to minimize the number of more costly compaction runs. As it is now the profiler structure can grow infinitely (till causes OOME) - it should be limited to a certain size, possibly using a system property to override the default value.

from btrace.

[author="joachimhskeie", created="Sun, 29 Aug 2010 11:02:38 +0200"]

Hello,

But the Profiler object will get GarbageCollected eventually ? I am calling Profiling.reset() every 7500 ms, so the Object should be available for GC ?

from btrace.

[author="joachimhskeie", created="Sun, 29 Aug 2010 18:23:18 +0200"]

I tried to increase -Xmx to 1 GB. It seems that the amout if com.sun.btrace.Profiler$Record classes quickly builds up to about 290000 instances, but that it doesn't exceed that amount. However, I am a bit curious about the number of byte-array object, which seems to be building up indefinately.

I will try to run the application without the BTrace Agent to see if the application still builds up a large about of byte-array objects, which would put BTrace in the clear for this issue.

from btrace.

[author="jbachorik", created="Sun, 29 Aug 2010 19:22:46 +0200"]

I've found the problem. The profiler data buffer was not deallocated upon calling the reset method. Only the data pointer was moved to the beginning but the data itself was left there to be overwritten (the buffer wouldn't grow for some time but it could lead to problems with memory anyway).
Fixing - http://kenai.com/projects/btrace/sources/hg/revision/389

from btrace.