Re: [Edbrowse-dev] gc

[Adam Thompson <arthompson1990@gmail.com>]

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.