Re: [Edbrowse-dev] gc

[Adam Thompson <arthompson1990@gmail.com>]

On Sat, Jan 04, 2014 at 05:14:14PM -0500, Karl Dahlke wrote:
> I have always wondered about gc in c++.
> It cannot be easy and straightforward like it is in java.
> (One reason I was always afraid of c++)
> So possibly void * won't work, like you have to tell the compiler
> that it's a pointer to a certain object of a certain class,
> for c++ to keep it around.

No, c++ doesn't have its own GC, but it does have the concept of object
constructors and destructors. If I understand the mozilla api correctly,
they basicly use these to hook into their javascript GC system such that when a
RootedObject (I think I've got the type name correct)
is constructed it tells the javascript GC not to collect the object pointed to
by the RootedObject instance, and when the afore mentioned instance goes out of
scope or is destroyed, its destructor tells the javascript GC that the
RootedObject instance is no longer alive and thus,
if all references to the javascript object are destroyed,
the javascript object should be collected.

The problem for us is that we currently don't construct any of these
RootedObject instances, which means that the SpiderMonkey internal GC doesn't
know we want to keep anything we create.
This basicly means (I think) that our objects are collected very soon after they're created, causing the segfault problem.
Another important note is this also applies to javascript values (strings etc) and a copule of other things.

As I see it, either we start keeping pointers to these GC constructs (in void *
should be fine) or we add a further layer of abstraction to basicly make a
more c-like api. Something like an explicit registration and unregistration
setup, with *all* the javascript stuff being in a single void * (runtime,
context list etc).
I think the first option may be the easier short term fix, though it's going to lead to much typecasting.

Cheers,
Adam.