Re: [Edbrowse-dev] gc

[Adam Thompson <arthompson1990@gmail.com>]

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.