Re: [gui-dev] Chasing possible memory leaks?

Hi Philippe,

If you could resend this patch and explain where the optimizations are 
that will reduce our memory problems, we'll take a much closer look at 
it.

Thanks much,
  Sam

On Thursday, August 19, 2004, at 04:50  PM, Philippe Verdy wrote:

> From: "Jens-Uwe Mager" <[email protected]>
>> While running as an ultrapeer my machines appear to go out of memory
>> somehow. I did a few runs with -Xrunhprof:heap=sites and I have a few
>> questions if that memory usage is about to be expected. The top 
>> entries
>> in the list of hot sites are these:
>>
>> SITES BEGIN (ordered by live bytes) Wed Aug 18 13:22:34 2004
>>           percent         live       alloc'ed  stack class
>>  rank   self  accum    bytes objs   bytes objs trace name
>>     1 11.41% 11.41% 11428008 1214 22449936 11149 60808 [J
>>     2  5.67% 17.08%  5676336 114744 6247840 125345 60656 [C
>>     3  2.54% 19.63%  2545920 6120 2589184 6224 56176 java.lang.Object
>>     4  2.54% 22.17%  2545920 6120 2589184 6224 56299 java.lang.Object
>>     5  2.54% 24.71%  2545920 6120 2589184 6224 56171 java.lang.Object
>>     6  2.54% 27.26%  2545920 6120 2589184 6224 56181 java.lang.Object
>>     7  2.43% 29.69%  2435648 29614 2576640 31128 51089 [C
>>     8  2.37% 32.06%  2374104 98921 2602368 108432 60620 
>> java.lang.String
>>     9  1.93% 33.99%  1930240 4640 1970176 4736 59661 java.lang.Object
>>    10  1.93% 35.92%  1930240 4640 1970176 4736 59636 java.lang.Object
>>    11  1.93% 37.85%  1930240 4640 1970176 4736 59646 java.lang.Object
>>    12  1.93% 39.77%  1930240 4640 1970176 4736 59641 java.lang.Object
>>
>> The first entry appears to relate to this stack trace:
>>
>> TRACE 60808:
>>         
>> com.limegroup.gnutella.util.BitSet.ensureCapacity(BitSet.java:140)
>
> I know that, and I have submitted a patch to the QRP table handling 
> classes
> several months ago.
> The problem is that, despite QRP tables should have a fixed size, 
> which is
> known immediately after the Reset message has been received, it won't 
> evolve
> again. Applying patches later will mean that the underlying Bitset 
> will grow
> progressively, causing lots of reallocations (and lots of dead long[]
> objects as seen above).
>
> However I don't know what happened to the patch I submitted then, 
> which also
> contained an faster, fully pipelined, version of the patch message 
> decoder
> and decompressor, that almost always avoid the creation of intermediate
> buffers.
>
> I have reworked it since then locally, but may be I should resend it. I
> know, with my version, that there are still leaf nodes trying to inject
> 1Megabit QRP tables to us, and that this still breaks when computing 
> merged
> 64Kbit QRP tables for UP-to-UP QRP routing: apparently this is a
> synchronization problem between the connection threads that receive and
> decode the QRP tables from leaves, and the thread that updates the 
> merged
> QRP table for sending patches to other UP: in some case the source 
> table is
> not resized as it should.
>
> Also, when resizing tables to 64K, we unnecessarily reallocate it each 
> time
> for each source leaf connection. This is not necessary, and a single 
> work
> 64K table should be enough to compute the merged version on the fly. 
> This is
> really inefficient, and it is effectively the main cause of dead 
> objects in
> the VM when running as an UltraPeer with lots of leaf connections.
>
> _______________________________________________
> gui-dev mailing list
> [email protected]
> http://www.limewire.org/mailman/listinfo/gui-dev
>

_______________________________________________
gui-dev mailing list
[email protected]
http://www.limewire.org/mailman/listinfo/gui-dev