From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by hurricane.the-brannons.com (Postfix) with ESMTPS id D209D77894 for ; Fri, 31 Jan 2014 09:33:46 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id x13so9274697wgg.15 for ; Fri, 31 Jan 2014 09:33:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=uVHNf+joeeQno8y3e0oi+KOeIyzg3vzDA3dCX7xjrYA=; b=aSJTlftMowdYwu1Z+d2sgAFjJ9Sdgj1aFp5sBJ55pzVb2LKZNoSZmxMHcJq/bH1YnE qw5ZudNocxjQxhAoZwF2B7N2s+U5Vf/zk3RYmrqH5STQlrTKjQ7r3QMPatOaKfVor+cg H9wGzVrgYBo4zo1ynZ2KM0s1YwN5sq6DuNJ7gSX+mALlInNMj7fWGN7Zt4WereCI+6XV vS2QnXkotEa5OzkErwZLwigCeR0Eih8LJqdJPF8MKCpCU71IA3VEXgxJwN7DdWWi3T7L ozgdV4kbRuJGrl82vM+nGoNvFjMNJoBa5kaUK6veJUM28Ktr0xGJsVRNgQz39clBSpru hWIQ== X-Received: by 10.180.107.1 with SMTP id gy1mr14574131wib.47.1391189598248; Fri, 31 Jan 2014 09:33:18 -0800 (PST) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by mx.google.com with ESMTPSA id cx3sm4866833wib.0.2014.01.31.09.33.16 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 31 Jan 2014 09:33:17 -0800 (PST) Date: Fri, 31 Jan 2014 17:33:14 +0000 From: Adam Thompson To: Karl Dahlke Message-ID: <20140131173314.GC10437@toaster.adamthompson.me.uk> References: <20140031080220.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140031080220.eklhad@comcast.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Edbrowse-dev@lists.the-brannons.com Subject: Re: [Edbrowse-dev] [PATCH] Use the list class from the C++ STL,... X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.17 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 17:33:47 -0000 On Fri, Jan 31, 2014 at 08:02:20AM -0500, Karl Dahlke wrote: > > The only useful reason I could see for this change is handling nulls in names > > To me the reason to make a change at all, and I grant you it ain't broke, > is to get rid of all those warning messages. > In the linux kernel they encourage you to make such changes, > even in working code, > and it's surprising how you can compile the kernel, zillions of > lines of code, and how few warnings there are. > In contrast js 24 gives pages and pages of warnings, > so that you can't tell if any of them should be taken seriously. Agreed, but the change from char * to string wouldn't fix any of the js24 warnings. Most of them go away with the -Wno-invalid-offsetof in JS_CXXFLAGS (I know this isn't nice, but they're Mozilla's warnings which we can't fix). > In that sense Chris' original patch does the trick, and I'm ok with that. Yeah, switching to the c++ list class makes sense here. Also, in the spirit of removing warnings, my gcc gives me a bunch of warnings in url.c about using int and size_t interchangably. Do you mind if I go ahead and fix these? > I just thought it might not be much more work > to put the struct right in the list, rather than struct * with manual allocs. > And maybe clean up the code a bit. > Guess that's Chris' call. Yeah, but then we've still got the cw->tags array to worry about. I wonder if we could have the stack as a void * (as you suggest) and then get whatever needs to use it to use c++? Which file is it actually rendered in? If it's one of the existing c++ ones then this'd allow us to get rid of the tag array, and thus the need for all those pointers. If not, then I don't know. > As for line count, I may be able to push from 10 million to 100 million, > but probably not more than that because of the way > files are represented with arrays inside, > having 4 byte indexes etc. > > There is another factor wherein you can run out of your 10 million lines > not because they are really being used, > but because there is no garbage collector for lines. > Make a substitution, and of course you have the new line, but I > have to keep the old one in case of an undo. > Make another change and I suppose I could get rid of that original line, > and yes it is freed (no memory leak), > but the index inside is not reclaimed. > The indexes march on towards 10 million. > So after a long edbrowse session you could run into this, even though you don't > have 10 million lines active now. > I've been meaning to address this in some fashion for, > or er um, at least a decade. > Well probably push the limit to 100 million first, that's more important > and easier, then think about better gc procedures for the line indexes. Yeah. Not sure how to do this without getting the equivalent of memory fragmentation in the lines array! The only way around this would be to switch from an array of lines to a linked list of them so you could swap out lines as needed. This'd be less memory-efficient for small numbers of lines but would make switching lines in and out much easier. This'd also get rid of the hard limit on lines completely I think (unless I'm missing something). > > I have played with jsrt for a while but haven't been able to produce > your seg fault. > And the one that I had earlier, reproducible, > went away with js 24. > I'll keep fishing around to see if I can trip another one. Thanks. Cheers, Adam.