mozilla

Compare Revisions

GCIntegration

Change Revisions

Revision 1491:

Revision 1491 by billm on

Revision 1492:

Revision 1492 by billm on

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

Revision 1491
Revision 1492
n56      In the leftmost frame, object B is already marked. Objects n56      Assume object B is already marked, as in the leftmost frame
>A and C have not been marked yet. Assume that in the middle frame>, while objects A and C have not been marked yet. In the middle f
> some code creates a pointer from B to C and destroys the pointer>rame some code creates a pointer from B to C and destroys the poi
> from A to C. In the last frame, A is marked. C is never marked e>nter from A to C. In the last frame, A gets marked by the GC. The
>ven though it's reachable. In the first frame, A hadn't been mark> problem is that C is never marked even though it's reachable. Th
>ed yet, so there was no need to mark C. In the last frame, B will>is will likely lead to a crash if C is accessed via B.
> not mark C because its marking is already finished. 
n62      All the schemes for preventing this sort of thing require wn62      All the schemes for preventing this sort of thing require w
>rite barriers. Every time a pointer is updated, a small amount of>rite barriers. Every time a pointer is updated, a small amount of
> code runs that may mark one of the objects involved in the updat> code runs that may mark one of the objects involved in the updat
>e. This only happens if an incremental GC is in progress. SpiderM>e. This only happens if an incremental GC is in progress. SpiderM
>onkey uses a simple barrier commonly called "snapshot at the begi>onkey uses a simple barrier commonly called a "snapshot at the be
>nning". The fundamental invariant that this barrier scheme guaran>ginning" barrier. The fundamental invariant that this barrier gua
>tees is that any object reachable when the incremental GC started>rantees is that any object reachable when the incremental GC star
> will be marked. In addition, objects allocated during the increm>ted will be marked. In addition, objects allocated during the inc
>ental GC are marked unconditionally. At the end of the GC, any re>remental GC are marked unconditionally. At the end of the GC, any
>achable object must have been newly allocated or else reachable a> reachable object must have been newly allocated or else reachabl
>t the beginning, since objects can never go from unreachable to r>e at the beginning, since objects can never go from unreachable t
>eachable. The end result is that all reachable objects are marked>o reachable. The end result is that all reachable objects are mar
>.>ked.
n78      <li>If a pointer is a root, then we guarantee that it will n78      <li>Some pointers are guaranteed to be marked in the first 
>be marked in the first slice of the GC. Therefore, it's not possi>slice of the GC. Therefore, it's not possible for code to modify 
>ble for code to modify it between when the initial snapshot is ta>them between when the initial snapshot is taken and when the poin
>ken and when the pointer is marked. Consequently, roots don't nee>ter is marked, so no write barrier is needed. Many pointers in Ge
>d to have a write barrier. Many pointers in Gecko are traced via >cko are traced via <span class="p"><a class="d external" href="ht
><span class="p"><a class="d external" href="http://mxr.mozilla.or>tp://mxr.mozilla.org/mozilla-central/ident?i=NS_DECL_CYCLE_COLLEC
>g/mozilla-central/ident?i=NS_DECL_CYCLE_COLLECTION_SCRIPT_HOLDER_>TION_SCRIPT_HOLDER_CLASS">NS_DECL_CYCLE_COLLECTION_SCRIPT_HOLDER_
>CLASS">NS_DECL_CYCLE_COLLECTION_SCRIPT_HOLDER_CLASS</a> and its r>CLASS</a> and its related macros. These pointers are always trace
>elated macros. These pointers are considered roots and so they do>d in the first slice, and so they don't need a write barrier.</sp
>n't need a write barrier.</span>>an> Many other XPConnect pointers are also traced in this way. Se
 >e <a class=" external" href="http://mxr.mozilla.org/mozilla-centr
 >al/search?string=XPCJSRuntime%3A%3ATraceBlackJS" title="http://mx
 >r.mozilla.org/mozilla-central/search?string=XPCJSRuntime%3A%3ATra
 >ceBlackJS">XPCJSRuntime::TraceBlackJS</a> and <a class=" external
 >" href="http://mxr.mozilla.org/mozilla-central/search?string=XPCJ
 >SRuntime%3A%3ATraceGrayJS" title="http://mxr.mozilla.org/mozilla-
 >central/search?string=XPCJSRuntime%3A%3ATraceGrayJS">XPCJSRuntime
 >::TraceGrayJS</a>.
n91      "Weak pointers" are a major complication to the scheme descn91      "Weak pointers" are a major complication to the scheme desc
>ribed above. For the purposes of this article, a weak pointer is >ribed above. For the purposes of this article, a weak pointer is 
>one that is not traced during GC. At the end of the GC, if it poi>one that is not traced during GC. At the end of the GC, if the po
>nts to an object that is not reachable via some other path, then >inter refers to an object that is not reachable via some other pa
>it will be nulled out or dropped in some way. If the object is st>th, then it will be nulled out or dropped in some way. If the obj
>ill reachable, then the pointer will be left alone. To see how we>ect is still reachable, then the pointer will be left alone. To s
>ak pointers can cause trouble, consider the following situation:>ee how weak pointers can cause trouble, consider the following si
 >tuation:
n112      There are two forms of moving GC we are likely to implementn112      There are two forms of moving GC we are likely to implement
>: generational GC and compacting GC. In generational GC, certain >: generational GC and compacting GC. In generational GC, certain 
>newly allocated are moved from one place (a nursery) to another (>newly allocated are moved from one place (a nursery) to another (
>the tenured space). At least initially, only JSStrings and JSObje>the tenured space). At least initially, only JSStrings and JSObje
>cts without finalizers will be allocated in the nursery, and only>cts without finalizers will be allocated in the nursery, and so o
> they will be subject to moving. Compacting GC is more exhaustive>nly they will be subject to moving. Compacting GC is more exhaust
>: every object is subject to moving.>ive: every object is subject to moving.
n118      To implement moving GC, we will remove the conservative stan118      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>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>ill replace it, but whatever it is will likely resemble auto-root
>ers. The main difference is that <em>every</em> reference will ne>ers. The main difference is that <em>every</em> reference will ne
>ed to be rooted. For example, the following code will be incorrec>ed to be rooted. For example, the following code will be incorrec
>tly:>t:
n126      If a GC runs in the middle of this and obj1/obj2 is moved, n126      If a GC runs in the middle of this code, and if obj1/obj2 i
>then the obj1 pointer will be updated to point to the new locatio>s moved, then the obj1 pointer will be updated to point to the ne
>n. The obj2 pointer will not, and it will contain garbage. We hav>w location. The obj2 pointer will not, and it will contain garbag
>e a three-pronged strategy for ensuring correctness:>e.
127    </p>
128    <p>
129      We have a three-pronged strategy for ensuring that no auto-
 >rooters are missing:
n133      <li>There's also a static analysis in the works that uses Sn136      <li>There's also a static analysis in the works that uses S
>ixgill. I'm not sure how up-to-date it is.>ixgill.
t140      We're even less sure of what will happen with pointers to Gt143      Pointers to GC things from the heap must be treated differe
>C things from outside the JS engine. For pointers that are traced>ntly because they don't have stack-like lifetimes. For pointers t
>, via JS_CALL_TRACER, we will most likely change the API so that >hat are traced via JS_CALL_TRACER we will most likely change the 
>the <em>address</em> of the pointer being traced is passed in, ra>API so that the <em>address</em> of the pointer being traced is p
>ther than the pointer itself. Then, if we need to move the object>assed in, rather than the pointer itself. Then, if we need to mov
>, we'll update the pointer to it as well.>e the object, we'll update the pointer to it as well.

Back to History