mozilla

Compare Revisions

GCIntegration

Change Revisions

Revision 1492:

Revision 1492 by billm on

Revision 1493:

Revision 1493 by billm on

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

Revision 1492
Revision 1493
n78      <li>Some pointers are guaranteed to be marked in the first n78      <li>Some pointers are guaranteed to be marked in the first 
>slice of the GC. Therefore, it's not possible for code to modify >slice of the GC. Therefore, it's not possible for code to modify 
>them between when the initial snapshot is taken and when the poin>them between when the initial snapshot is taken and when the poin
>ter is marked, so no write barrier is needed. Many pointers in Ge>ter is marked, so no write barrier is needed. Many pointers in Ge
>cko are traced via <span class="p"><a class="d external" href="ht>cko are traced via <span class="p"><a class="d external" href="ht
>tp://mxr.mozilla.org/mozilla-central/ident?i=NS_DECL_CYCLE_COLLEC>tp://mxr.mozilla.org/mozilla-central/ident?i=NS_DECL_CYCLE_COLLEC
>TION_SCRIPT_HOLDER_CLASS">NS_DECL_CYCLE_COLLECTION_SCRIPT_HOLDER_>TION_SCRIPT_HOLDER_CLASS">NS_DECL_CYCLE_COLLECTION_SCRIPT_HOLDER_
>CLASS</a> and its related macros. These pointers are always trace>CLASS</a> and its related macros. These pointers are always trace
>d in the first slice, and so they don't need a write barrier.</sp>d in the first slice, and so they don't need a write barrier.</sp
>an> Many other XPConnect pointers are also traced in this way. Se>an> Many other XPConnect pointers are also traced in this way. Se
>e <a class=" external" href="http://mxr.mozilla.org/mozilla-centr>e <a class="external" href="http://mxr.mozilla.org/mozilla-centra
>al/search?string=XPCJSRuntime%3A%3ATraceBlackJS" title="http://mx>l/search?string=XPCJSRuntime%3A%3ATraceBlackJS" title="http://mxr
>r.mozilla.org/mozilla-central/search?string=XPCJSRuntime%3A%3ATra>.mozilla.org/mozilla-central/search?string=XPCJSRuntime%3A%3ATrac
>ceBlackJS">XPCJSRuntime::TraceBlackJS</a> and <a class=" external>eBlackJS">XPCJSRuntime::TraceBlackJS</a> and <a class="external" 
>" href="http://mxr.mozilla.org/mozilla-central/search?string=XPCJ>href="http://mxr.mozilla.org/mozilla-central/search?string=XPCJSR
>SRuntime%3A%3ATraceGrayJS" title="http://mxr.mozilla.org/mozilla->untime%3A%3ATraceGrayJS" title="http://mxr.mozilla.org/mozilla-ce
>central/search?string=XPCJSRuntime%3A%3ATraceGrayJS">XPCJSRuntime>ntral/search?string=XPCJSRuntime%3A%3ATraceGrayJS">XPCJSRuntime::
>::TraceGrayJS</a>.>TraceGrayJS</a>.
tt151    <h4>
152      Write barriers
153    </h4>
154    <p>
155      Generational GC needs its own write barrier. The goal is to
 > keep a list, called the remembered set, of all pointers from the
 > tenured generation into the nursery. So every time a pointer is 
 >written somewhere, we need to check if the source is in the tenur
 >ed gen and if the destination is in the nursery. If so, the point
 >er is added to the remembered set. The remembered set allows us t
 >o collect the nursery without needing to look at the tenured gene
 >ration at all, aside from the remembered set entries.
156    </p>
157    <p>
158      There are three simplifications, similar to the ones for in
 >cremental write barriers, that will allow us to avoid write barri
 >ers in some cases.
159    </p>
160    <ul>
161      <li>Only strings and objects without finalizers will be sto
 >red in the nursery, at least initially. Consequently, if the thin
 >g being stored is known to have a finalizer, then there is no nee
 >d for a write barrier. Note that what matters is the value being 
 >written--if the object being written to has a finalizer, a write 
 >barrier may still be required.
162      </li>
163      <li>If a pointer is not traced, as by JS_CALL_TRACER, then 
 >there is no need for a write barrier.
164      </li>
165      <li>If a pointer is a root, then that pointer will be scann
 >ed during every nursery collection, so there is no need for a wri
 >te barrier. As above, this means that classes governed by <span c
 >lass="p"><a class="d external" href="http://mxr.mozilla.org/mozil
 >la-central/ident?i=NS_DECL_CYCLE_COLLECTION_SCRIPT_HOLDER_CLASS">
 >NS_DECL_CYCLE_COLLECTION_SCRIPT_HOLDER_CLASS</a> do not need a wr
 >ite barrier on their fields.</span>
166      </li>
167    </ul>
168    <p>
169      We have not decided yet on an API for write barriers. We do
 >n't know yet how many there will be outside of the JS engine.
170    </p>

Back to History