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

Nothing has changed related to flow control & QRP in well over a few months,
so the likely conclusion is that it really is a pickup in message traffic
combined with the older addition of high outdegree (which would have no
caused memory problems while there was little traffic).

Getting even fancier with weak links might solve this. ;)

Thanks,
 Sam

> -----Original Message-----
> From: [email protected] [mailto:gui-dev-
> [email protected]] On Behalf Of Greg Bildson
> Sent: Thursday, August 19, 2004 10:42 AM
> To: [email protected]
> Subject: RE: [gui-dev] Chasing possible memory leaks?
> 
> It's been a long while since flow control kicked in.  Those
> PriorityMessageQueues could be somewhat troublesome with the recent pickup
> in message traffic.  However, it almost sounds like your connections (and
> QRP tables) keep building up.  Perhaps some closes got lost or are we
> trying
> to do something too fancy with weak links now?
> 
> Thanks
> -greg
> 
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Jens-Uwe Mager
> Sent: Thursday, August 19, 2004 7:00 AM
> To: [email protected]
> Subject: [gui-dev] Chasing possible memory leaks?
> 
> 
> 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)
>         com.limegroup.gnutella.util.BitSet.set(BitSet.java:265)
> 
> com.limegroup.gnutella.routing.QueryRouteTable.handlePatch(QueryRouteTab
> le.java:462)
> 
> com.limegroup.gnutella.routing.QueryRouteTable.patch(QueryRouteTable.jav
> a:405)
> 
> com.limegroup.gnutella.ManagedConnection.patchQueryRouteTable(ManagedCon
> nection.java:395)
> 
> com.limegroup.gnutella.MessageRouter.handlePatchTableMessage(MessageRout
> er.java:2345)
> 
> com.limegroup.gnutella.MessageRouter.handleMessage(MessageRouter.java:34
> 8)
> 
> com.limegroup.gnutella.ManagedConnection.loopForMessages(ManagedConnecti
> on.java:995)
> 
> com.limegroup.gnutella.ConnectionManager.startConnection(ConnectionManag
> er.java:1943)
> 
> Does that mean that my machine needs 22MB of routing tables?
> 
> Ranks 2 to 6 appear all to be related, they all appear to revolve around
> this stack trace:
> 
> TRACE 56176:
>         com.limegroup.gnutella.util.Buffer.<init>(Buffer.java:47)
> 
> com.limegroup.gnutella.util.BucketQueue.<init>(BucketQueue.java:46)
> 
> com.limegroup.gnutella.connection.PriorityMessageQueue.<init>(PriorityMe
> ssageQueue.java:50)
> 
> com.limegroup.gnutella.ManagedConnection.buildAndStartQueues(ManagedConn
> ection.java:651)
> 
> com.limegroup.gnutella.ConnectionManager.connectionInitialized(Connectio
> nManager.java:1216)
> 
> com.limegroup.gnutella.ConnectionManager.completeConnectionInitializatio
> n(ConnectionManager.java:1834)
> 
> com.limegroup.gnutella.ConnectionManager.initializeExternallyGeneratedCo
> nnection(ConnectionManager.java:1814)
> 
> com.limegroup.gnutella.ConnectionManager.acceptConnection(ConnectionMana
> ger.java:333)
> 
> com.limegroup.gnutella.Acceptor$ConnectionDispatchRunner.run(Acceptor.ja
> va:592)
> 
> And the large number of strings in rank 8 appear to be from this trace:
> 
> TRACE 60620:
> 
> com.limegroup.gnutella.messages.QueryRequest.<init>(QueryRequest.java:12
> 49)
> 
> com.limegroup.gnutella.messages.QueryRequest.createNetworkQuery(QueryReq
> uest.java:854)
>         com.limegroup.gnutella.messages.Message.read(Message.java:303)
> 
> com.limegroup.gnutella.Connection.readAndUpdateStatistics(Connection.jav
> a:1084)
>         com.limegroup.gnutella.Connection.receive(Connection.java:1029)
> 
> com.limegroup.gnutella.ManagedConnection.receive(ManagedConnection.java:
> 481)
> 
> com.limegroup.gnutella.ManagedConnection.loopForMessages(ManagedConnecti
> on.java:970)
> 
> com.limegroup.gnutella.ConnectionManager.startConnection(ConnectionManag
> er.java:1943)
> 
> com.limegroup.gnutella.ConnectionManager.access$400(ConnectionManager.ja
> va:56)
> 
> I am not entirely sure if I am not barking up the wrong tree, but I get
> the feeling that there are a few memory leaks that appear to be
> triggered if I am turning ultrapeer on. If there is interest, the full
> trace file is here:
> 
> http://baghira.han.de/~jum/limewire.sites.gz
> --
> Jens-Uwe Mager	<pgp-mailto:F476EBC2>
> _______________________________________________
> 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

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