Compare Revisions

GCIntegration

Change Revisions

Revision 1489:

Revision 1489 by billm on

Revision 1490:

Revision 1490 by billm on

Title:
GCIntegration
GCIntegration
Slug:
SpiderMonkey/GCIntegration
SpiderMonkey/GCIntegration
Content:

Revision 1489
Revision 1490
nn20    </p>
21    <h3>
22      Overview
23    </h3>
24    <p>
25      Before digging too deep, here are some quick rules of thumb
 > for how to write code that will work smoothly with the GC regard
 >less of changes that happen in the future.
26    </p>
27    <ul>
28      <li>Try to structure things as follows: JSObjects can point
 > to C++ objects or to other GC things. But avoid having C++ objec
 >ts point to GC things (unless it's just to their own wrapper--tha
 >t's okay). If there is a choice between storing a GC thing inside
 > a C++ object or its JS corresponding representation, prefer to s
 >tore it in the JS representation.
29      </li>
30      <li>Never store GC things in a JSObject's private pointer (
 >i.e., via JS_SetPrivate). It's better to store them in reserved s
 >lots, since those will automatically be traced if the object is n
 >ative.
31      </li>
32      <li>As much as possible, avoid trace hooks. If objects are 
 >stuctured as described above, there should be no need for them.
33      </li>
34      <li>This should be obvious by now, but never ever allow a G
 >C thing point to a GC thing in a different compartment unless it'
 >s a wrapper that's registered in the cross-compartment wrapper ma
 >p.
35      </li>
36    </ul>
37    <p>
38      Now, on to the details...
n84      A very simple way to identify weak pointers is to look for n103      A very simple way to identify weak pointers is to look for 
>usage of <a class="external" href="http://mxr.mozilla.org/mozilla>usage of <a class="external" href="http://mxr.mozilla.org/mozilla
>-central/ident?i=JS_IsAboutToBeFinalized" title="http://mxr.mozil>-central/ident?i=JS_IsAboutToBeFinalized" title="http://mxr.mozil
>la.org/mozilla-central/ident?i=JS_IsAboutToBeFinalized">JS_IsAbou>la.org/mozilla-central/ident?i=JS_IsAboutToBeFinalized">JS_IsAbou
>tToBeFinalized</a>. If a pointer is weak, there's a good chance t>tToBeFinalized</a>. If a pointer is weak, there's a good chance t
>hat JS_IsAboutToBeFinalized is used to null it out if its referen>hat JS_IsAboutToBeFinalized is used to null it out if its referen
>t is about to be finalized. However, this search misses some case>t is about to be finalized. However, this search misses some case
>s like the wrapper cache, where <a class=" external" href="http:/>s like the wrapper cache, where <a class="external" href="http://
>/mxr.mozilla.org/mozilla-central/ident?i=ClearWrapper" title="htt>mxr.mozilla.org/mozilla-central/ident?i=ClearWrapper" title="http
>p://mxr.mozilla.org/mozilla-central/ident?i=ClearWrapper">ClearWr>://mxr.mozilla.org/mozilla-central/ident?i=ClearWrapper">ClearWra
>apper</a> is called directly from a finalizer.>pper</a> is called directly from a finalizer.
tt108    <h3>
109      Moving GC
110    </h3>
111    <p>
112      There are two forms of moving GC we are likely to implement
 >: generational GC and compacting GC. In generational GC, certain 
 >newly allocated are moved from one place (a nursery) to another (
 >the tenured space). At least initially, only JSStrings and JSObje
 >cts without finalizers will be allocated in the nursery, and only
 > they will be subject to moving. Compacting GC is more exhaustive
 >: every object is subject to moving.
113    </p>
114    <h4>
115      Stack roots
116    </h4>
117    <p>
118      To implement moving GC, we will remove the conservative sta
 >ck scanner. We don't have a fully formed plan in place for what w
 >ill replace it, but whatever it is will likely resemble auto-root
 >ers. The main difference is that <em>every</em> reference will ne
 >ed to be rooted. For example, the following code will be incorrec
 >tly:
119    </p>
120    <p>
121      <code>AutoRootedObject obj1 = ...;<br>
122      JSObject *obj2 = obj1;<br>
123      // use obj2</code>
124    </p>
125    <p>
126      If a GC runs in the middle of this and obj1/obj2 is moved, 
 >then the obj1 pointer will be updated to point to the new locatio
 >n. The obj2 pointer will not, and it will contain garbage. We hav
 >e a three-pronged strategy for ensuring correctness:
127    </p>
128    <ul>
129      <li>All SpiderMonkey APIs will require that only rooted obj
 >ects be passed to them. So you might be able to get your hands on
 > an unrooted object, but you won't be able to do anything with it
 >.
130      </li>
131      <li>Brian Hackett has written a dynamic analysis that uses 
 >the existing conservative stack scanner to find unrooted pointers
 > to GC things on the stack and poisons them. If these pointers ar
 >e ever used again, the program will crash. We expect to test heav
 >ily with this analysis.
132      </li>
133      <li>There's also a static analysis in the works that uses S
 >ixgill. I'm not sure how up-to-date it is.
134      </li>
135    </ul>
136    <h4>
137      Heap pointers
138    </h4>
139    <p>
140      We're even less sure of what will happen with pointers to G
 >C things from outside the JS engine. For pointers that are traced
 >, via JS_CALL_TRACER, we will most likely change the API so that 
 >the <em>address</em> of the pointer being traced is passed in, ra
 >ther than the pointer itself. Then, if we need to move the object
 >, we'll update the pointer to it as well.
141    </p>
142    <p>
143      For pointers that are not traced, the solutions become more
 > ad-hoc. It's likely that JS_IsAboutToBeFinalized will also be ch
 >anged to take the address of the pointer. If the given object is 
 >still alive, but it moved, then we can update the pointer. For wr
 >apper caches, we may add a new class hook that is invoked if the 
 >object moves. Objects with wrapper caches could implement that ho
 >ok to find their corresponding C++ object and update the wrapper 
 >field to point to the new location.
144    </p>
145    <p>
146      Undoubtedly there will be more esoteric cases. We will need
 > to handle pointers to array slots and string characters speciall
 >y, since those may actually be pointers into the middle of GC thi
 >ngs (inline slots or inline chars). We will need to explore how t
 >hese situations occur in the browser now, and how best to handle 
 >them.
147    </p>

Back to History