Hmm.. Can the problem be there there is no call to clear() on the pooled buffers anywhere?
Not sure wheter the limit(0) and position(0) calls does the same trick though. /N > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Niklas Bergh > Sent: den 10 september 2003 14:44 > To: 'Discussion of development issues' > Subject: RE: [freenet-dev] ... and this is why Java is bad. > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Toad > > Sent: den 9 september 2003 21:51 > > To: Discussion of development issues > > Subject: Re: [freenet-dev] ... and this is why Java is bad. > > > > > > On Tue, Sep 09, 2003 at 01:44:15PM -0700, Ian Clarke wrote: > > > On Tue, Sep 09, 2003 at 03:22:32PM -0400, Dan Merillat wrote: > > > > Ian, this is why we don't bother submitting JVM bugs. > Sun dosn't > > > > care. > > > > > > Oh come on! He is asking for more information - how do you > > interpret > > > that as "not caring"? When we ask someone for more > > information after > > > they report a but to us does that mean that we don't care? > > > > > > I know Sun is everybody's favourite whipping boy on this > > project, but > > > citing a request for further information on a bug report as > > evidence > > > that they don't care is rediculous. > > > > They execute the provided instructions for producing a crash. > > Then they get a crash. They have access to the innards of the > > JVM, we don't. They are much better qualified to debug what > > is clearly a JVM bug. I would also argue that by not > > providing FULL, compilable, distributible source code, they > > are automatically a reasonable target for abuse, just like > > Microsoft. :) > > > > However, we MAY be able to get a bit further with this - the > > recent change that seems to be responsible is me changing > > tcpConnection to use direct buffers, and to pool them, which > > was 6186 IIRC. I will revert this soon, motives were 1. use > > of direct buffers reduces memory allocation and copying, and > > 2. some recent reports of Java using far more RAM than > > Freenet reports, one reasonable explanation would be > > temporary direct buffers allocated by the JVM leaking, we can > > take control of this by using direct buffers. > > You might be right about that. When looked into the problem I > have encountered multiple different memory-related messages > right before the JVM chrashes (which occurred pretty much as > soon as the node has completed reading of the DS and started > communicate): > > Exception java.lang.OutOfMemoryError: requested 1024000 bytes > for GrET* in > D:/BUILD_AREA2/jdk1.4.2_01/hotspot\src\share\vm\utilities\grow > ableArray. > cpp. Out of swap space? > > Could not execute freenet.node.states.request.SendFinished@ > 1063183976546:1063183975468:true:null:freenet.Message: > DataRequest @null @ 63417fd518cbe52b @ 1063183993188: > java.lang.OutOfMemoryError: unable to create new native thread > > This happens even with the current CVS where > (useDirectBuffers == false) && (poolBuffers == true).... I am > currently going for a run with poolBuffers==false to see if > it makes any difference. > > Dan, do you think that this would be good to add to the case? > > /N > > _______________________________________________ > Devl mailing list > [EMAIL PROTECTED] > http://dodo.freenetproject.org/cgi-> bin/mailman/listinfo/devl > _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
