> -----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\growableArray. 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
