From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 3A31277AC7 for ; Sun, 5 Jan 2014 05:46:41 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id k14so15013944wgh.22 for ; Sun, 05 Jan 2014 05:46: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=DssT5rVwziqVvVvsjz/dbF4OBAXm8L9yAnFz85BsZIs=; b=nmCDvv84wtlOh0zkRzbYEWCfs/VGYDKAIziJjChA8kjUS/vw8fwLECKyWBRCl+G1oL jHBzNVXRwAUUS4hM9ZXyyvvLfPLO5zzODpipxasE6QB8waaU1IMg8T6+uXDOD5JL/WWb a7YaKZlgKR5lKJamV+2MepJPWlmgeO5bCKjP9oz4UqKVvJh0WdhuzNjqkHBatdU4Qtm2 YCHLXjhf2jc9fvu3oQLlGDY3w+xNU8Lb3KfycfZwM9TVbvxTz1jMGcQdVZGCqnYTBaGA Adh5LPHJ+bpJQqvSdWJAvwOBD/omILfWOJLngHpYj0z1JlxF6U4dM84LxjB4xFfSMH/m xmwA== X-Received: by 10.180.90.199 with SMTP id by7mr6146946wib.38.1388929585989; Sun, 05 Jan 2014 05:46: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 ey3sm12735270wib.4.2014.01.05.05.46.24 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 05 Jan 2014 05:46:25 -0800 (PST) Date: Sun, 5 Jan 2014 13:46:22 +0000 From: Adam Thompson To: Karl Dahlke Message-ID: <20140105134622.GD11201@toaster.adamthompson.me.uk> References: <20140005023044.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140005023044.eklhad@comcast.net> 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 13:46:41 -0000 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. Not quite. My understanding of the problem is this: Garbage collectors work by removing values (objects, strings, numbers etc) which, within the world of the language they're garbage collecting (javascript in our case) are no longer reachable (no references exist to them). Depending on the kind of GC used, they will do this every time a language operation is performed or periodically. When embedding a language into an application (like we are with javascript) the garbage collector only knows about the world inside the language environment (i.e. what objects have been created by javascript etc), and not that of the embedding (host) application. To allow the host app to create custom objects within the embedded language environment an api needs to exist to tell the garbage collector that the object which has just appeared within its environment is actually referenced in the outside world and is not left over from for example (excuse my rusty js syntax): var x = object(); x = object(); /* the previous value of x is now garbage */ What we're currently doing is constructing objects within the javascript environment but failing to tell the garbage collector that they're actually referenced in the outside world, thus they seem to get collected almost imediately. We then try to use these objects (either by defining references to them within the javascript environment or initialising standard classes within them or whatever), however they've already been freed, hence the segfaults. The key thing to note from the above is that the GC knows nothing about pointers etc within the host application (edbrowse) unless explicitly told about them. Calling object construction methods (JS_New etc) only creates an object within the javascript environment and returns a pointer to it so that the host app can act on it. It does not create a reference within the javascript environment. It's sort of like the line: object(); Rather than: var ref = object(); 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. Hope this helps somewhat, and appologies if it's confusing or you know it already (or both). Cheers, Adam.