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

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