On Wed, Sep 10, 2003 at 02:55:18PM +0100, Niklas Bergh wrote: > 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.
Should do. Documentation for clear() says it does just that: "clear() makes a buffer ready for a new sequence of channel-read or relative put operations: It sets the limit to the capacity and the position to zero." > > /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 -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
pgp00000.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
