Re: [EXPERIMENT] Emacs with the SpiderMonkey garbage collector

[Steve Fink <sfink@mozilla.com>]

Very interesting! I'm surprised and impressed that someone could get 
this to work, especially in a C project. (Servo is a C project that uses 
spidermonkey, but they do fancy things with the Rust type system and a 
bindings generator to bridge the gap.)

> 2. Replace Lisp_Object in the source code
>
> My plan was to use JS::Value objects instead of Lisp_Object.
>
> In order to properly use SpiderMonkey, stack objects must be rooted:
> I've decided to use separate types for (a) stack values and values in
> structs that live on the stack (b) values on the heap (c) values on
> structs that live on the heap (d) return values (e) function
> arguments. (In order, ELisp_Value, ELisp_Heap_Value,
> ELisp_Struct_Value, ELisp_Return_Value, ELisp_Handle).  While
> Lisp_Object values need to be protected, pointers to Lisp_Object need
> not, so there is a simple ELisp_Pointer type (which is currently
> bloated because it determines at run time whether it's pointing to an
> ELisp_Value or an ELisp_Struct_Value), as well as vector (resizeable
> arrays) and array (fixed size) types.
>
> Luckily, I was able to modify the C-to-C++ conversion script to
> determine automatically which of the replacement types to use for most
> of the ~10k instances of "Lisp_Object" in the Emacs source code. In
> fact, I decided to keep this approach, modifying the C source code as
> little as necessary, then turning each .c or .h file in the src
> directory into a C++ .c.cc or .h.hh file, then (ideally) not modifying
> the resulting C++ files.  It's currently not quite clean that way.

Within Gecko (the Firefox rendering engine) and internally to 
SpiderMonkey, it's very similar though we don't do anything special for 
return values. For a base type of JSObject (the structure actually 
stored in the GC heap), we have

  - JSObject* - return value

  - Rooted<JSObject*> - stack value or member of stack struct.

Rooted is an RAII class that inserts/removes from a list of stack roots.

  - Heap<JSObject*> - member of struct in the heap

  - Handle<JSObject*> - constant parameter, just a type-safe alias for 
JSObject**

  - MutableHandle<JSObject*> - mutable parameter (out parameter), again 
an alias for JSObject**

If you know you're doing stuff that can't GC, then you can just use 
plain JSObject*.

For JS::Value, which boxes up various types of values or pointers, they 
would be Value, Rooted<Value>, Heap<Value>, Handle<Value>, and 
MutableHandle<Value>.

> 6. Calling convention
>
> The usual SpiderMonkey calling convention is that functions do not
> return GC types; their arguments are "handles", essentially read-only
> pointers to JS::Values.  I decided to return JS::Value objects
> directly (except for being wrapped in another class), which opens up
>   a race condition:  If f1 and f2 are functions returning
> ELisp_Return_Type values, it's illegal to call another function g as
> g(f1(...), f2(...)).  f1's return value will not be traced if f2
> triggers a GC, so if it is moved there will be a segfault (or worse).
> It should be possible to further extend my C-to-C++ script to deal
> with this by automatically assigning ELisp_Value temporaries in this
> situation. I also decided to pass function arguments as JS::Value
> objects, rooting them in the callee instead. Both of these decisions
> are open to revision.

A fair number of functions do return GC pointers directly, there's 
really nothing against doing that (in our code base, that is; see 
below). But most of those are allocation functions. The reason why we 
don't generally return GC pointers is not because of the precise GC, but 
rather because we compile without exceptions so the return value is 
reserved for a boolean status.

Early in the precise GC project (we used to have a conservative stack 
scanner), we tried using a different type for return values, but it 
didn't work out.

You are absolutely right about the hazards of g(f1(...), f2(...)). That 
is but one of the tricky patterns that we had littering our code, even 
after we supposedly went through and fixed everything up. We are 
absolutely dependent on a static "rooting hazard" analysis that we run 
on every checkin. The above is one tricky pattern we rely on it for 
detecting. Another is methods on a GC thing; the 'this' pointer will 
implicitly be on the stack and so could get invalidated anytime you GC. 
Probably the trickiest is when you have an RAII class that can GC in its 
destructor, and you're returning a GC pointer -- the pointer could get 
invalidated in between a 'return' statement and the caller resuming! The 
latter is obviously not an issue for a C embedding.

The analysis is implemented as a GCC plugin and postprocessing scripts, 
and in theory can be run on an embedding project's code. In practice, 
it's generally a pain to integrate it into the build system; there are 
wrappers you can put in your path to have it automatically called in 
place of gcc/g++ (the wrappers just invoke gcc with the correct -fplugin 
arguments), but in practice it tends to be a pain to get that to 
cooperate happily with eg configure scripts. I recently tried doing it 
for the GNOME shell, which embeds spidermonkey, but couldn't get their 
build system happy after an hour or two of trying. If you're interested 
in trying, you could find me (sfink) on irc.mozilla.org in the #jsapi 
channel. It's very straightforward to get a list of problems to fix, one 
after another, which should resolve most weird crashes.

The one big thing that the analysis doesn't handle particularly well is 
internal pointers. For now, it sounds like you're mostly safe from these 
moving because all your data is hanging off of the JS_GetPrivate 
indirection, so you wouldn't have any pointers internal to GC things. 
But you can still run into issues keeping things alive. We mostly have 
this problem with strings, since small strings are stored inline in the 
GC things and so it's very easy to end up with a char* that will move. 
We tend to work around this by either (1) passing around the GC pointer 
instead of the char*; (2) making functions that accept such a char* to 
also declare that they won't GC by requiring a reference to an 
'AutoRequireCannotGC&' token, which is validated by the static analysis; 
or (3) forcing the contents to be stored in the malloc heap if they 
aren't already, and just being careful with keeping the owning JSString* 
in a Rooted<JSString*> somewhere higher on the stack.

Collections are also an issue, if you want to index them by GC pointer 
value.

Note that if you disable the nursery (generational GC) and never request 
a compacting GC, then you should be able to use the SpiderMonkey GC as a 
nonmoving collector. It's still precise, so you still have to root 
things to make sure they stay alive, but at least they won't move around 
underneath you. Given the performance benefits of generational 
collection, though, it's probably not the best way to answer the 
question of how to make it possible to swap GC engines.

If you're still suffering from too much time on your hands, you might 
want to compare with the V8 GC embedding API. I don't know too much 
about it, but my impression is that although it's still precise, it has 
a more pleasant root scoping setup that makes it possible to safely 
embed without having a separate static analysis. My anecdotal data 
suggests that people who have used both don't seem to have a clear 
preference for one or the other, so apparently there are other issues. 
But it's another data point as to what would be required to adopt a 
different GC engine. And you've already shown a masochistic streak...

One last note: I don't know how you're doing timings, but DEBUG 
spidermonkey builds are much, much, much slower. We do a crazy amount of 
sanity checking, including redundant whole-heap scans to verify various 
invariants. So develop with DEBUG (the assertions are essential for 
using JSAPI correctly, even for experienced users) but ignore any speed 
estimates until you try a non-DEBUG, preferably optimized build.