Revision 1490 Revision 1491 n 8 This page is intended to be a brief summary of how Gecko/Fi n 8 The SpiderMonkey GC will be changing a lot in the future. T > refox should interact with the SpiderMonkey GC. Much of the GC is > his page is intended to explain the changes that are happening, w > in flux right now, so the goal is more to explain the direction > ith a focus on how they will affect Gecko code that uses JSAPI. A > we're heading and what's likely to be safe or unsafe. At a high l > t a high level, there are three issues to be aware of: > evel, there are three issues to be aware of: n 19 The APIs for GC/CC interaction and incremental GC are alrea n 19 The APIs for GC/CC interaction and incremental GC are alrea > dy in place. Development of moving GC (both generational and comp > dy in place. Development of moving GC (both generational and comp > acting) are under way, but only in the JS shell so far. However, > acting) is under way, but only in the JS shell so far. We're stil > we should try to design new code, like the DOM bindings, to avoid > l thinking about how the APIs for moving GC should work. > friction with moving GC as much as possible. t 28 <li>Try to structure things as follows: JSObjects can point t 28 <li>Avoid having C++ objects that point to JS objects (unle > to C++ objects or to other GC things. But avoid having C++ objec > ss it's just to their own wrapper--that's okay). It's safe for JS > ts point to GC things (unless it's just to their own wrapper--tha > objects to point to other JS objects or to C++ objects. If there > t's okay). If there is a choice between storing a GC thing inside > is a choice between storing a GC thing inside a C++ object or it > a C++ object or its JS corresponding representation, prefer to s > s JS corresponding representation, prefer to store it in the JS r > tore it in the JS representation. > epresentation.