From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 5B5D777AC7 for ; Sun, 5 Jan 2014 11:52:40 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id u56so14879954wes.22 for ; Sun, 05 Jan 2014 11:52:27 -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=yxAB0qgACN3Sr4XdF5J1pw36buEZrNMvyJDkhBTZuwU=; b=rSd21hIBOMUFFqNdmFhuRdtraFIE/hKhJZ74qJ5V0R7qAkxgtjSTK+2M0kX5Try78Q NF01sbQ0TtfUYMvK6OG7FKYbH2k4voOtcQD76C6SD50yFZPisRTNuksHr0HB6HuH5p9a BULAZsrUFNyxcLEl41T9F0vXwmD6OkK5HeMxkVU/m7UbNe78pUOOXa/yKnOJ5j4wSJMZ FvwS/DkYLmEbhWRi5KMi5SiSWqQ1f+6tg+w1J3RbguJ1WaM+dpHI+82TnQXoJwC8nZNM qOB4Sv1Kev1tXxH/QZ1Gx6lnUSXgRbMNzCDMNoIctJF5UJsDn8LR5scq4i4RkODBdTjt 7sbA== X-Received: by 10.180.106.165 with SMTP id gv5mr9646698wib.32.1388951545875; Sun, 05 Jan 2014 11:52:25 -0800 (PST) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by mx.google.com with ESMTPSA id j9sm40843011wjx.18.2014.01.05.11.52.24 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 05 Jan 2014 11:52:25 -0800 (PST) Date: Sun, 5 Jan 2014 19:52:22 +0000 From: Adam Thompson To: Karl Dahlke Message-ID: <20140105195222.GF11201@toaster.adamthompson.me.uk> References: <20140005023044.eklhad@comcast.net> <20140105134622.GD11201@toaster.adamthompson.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140105134622.GD11201@toaster.adamthompson.me.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Edbrowse-dev@lists.the-brannons.com Subject: Re: [Edbrowse-dev] gc 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: Sun, 05 Jan 2014 19:52:40 -0000 On Sun, Jan 05, 2014 at 01:46:22PM +0000, Adam Thompson wrote: > On Sun, Jan 05, 2014 at 02:30:44AM -0500, Karl Dahlke wrote: > > > The problem for us is that we currently don't construct any of these > > > RootedObject instances, which means that the SpiderMonkey internal GC > > > > Really? > > My layer calls, for example, JS_ConstructObjectWithArguments() > > to make a new object, > > I would suppose you replace that with some kind of js new call, > > which implicitly or explicitly creates a new object in c++, > > which calls the constructor you described, > > and I would figure that's good enough to keep it around, > > until we remove it, which use to be some kind of js_free, > > now some kind of js_destroy, > > and then the gc can clean up the loose ends, > > and I'm sorry in advance if I'm oversimplifying it, > > because I haven't looked at any of your code or how it works; > > I just didn't expect a problem here. > > Allocate becomes new construct, and all should be well. > > I'm guessing this wasn't an issue before since you had to explicitly call the > GC so you had time to insert the references into the environment (i.e. > make jwin the global object), however now it seems to be called as part of most operations. > > To allow this to work they now have the rooting api, > which as far as I can work out, provides objects which are like the "smart" > pointers chris was talking about. Instead of just freeing the object however, > these ones hook into the GC for the javascript environment allowing objects to > stay around in the environment until all references, > including those in the host app, are gone. Ok, on closer inspection it looks like we've been living dangerously for a while as JS_Add*Root functions are present in smjs 185 as well. The good news is I discovered this whilst looking for a non-c++ alternative to the smart pointers approach, and the fact that it still exists and is still supported (though is only encouraged when absolutely necessary) means that I can save myself a whole bunch of work. The bad news is that there's been a set of GC-related bugs there for, well, however long edbrowse's been using SpiderMonkey I guess. This supports my suspicions that the GC is probably behind many of the js related segfaults since we really should've been telling it about most of the js stuff we do. The reason this is more of an issue now is because they've improved their GC to make it much more memory efficient apparently. Cheers, Adam.