Thanks for the quick replies! One more question: If a Context pointer is archived into a ThreadState, will the garbage collector change that pointer in the ThreadState so that when the Context pointer is restored it points to the new memory? Specifically, I've been having issues with corrupted Context objects and the scenario I'm wondering about is:
1) In thread A, a Unlocker is instanced in a stack and thread A continues calling code 2) In thread B, a Locker is instanced on the stack, calls RestoreThread which in turn calls EagerlyArchiveThread which archives Top (including its Context pointer) into a ThreadState (this is the state from thread A) 3) In thread B, a garbage collection event happens, and the Context from thread A that was archived is moved. 4) In thread B, the Locker goes out of scope, is destroyed, and sets up for lazy archiving of thread B's current state. Thread A's state is still archived. 5) In thread A, a Locker is instanced on the stack, the current state (for thread B) is archived and the previously archived state for thread A is restored, including a pointer to the Context that was moved. Now, my question is, if this happens will that Context pointer that is restored in thread A point to the new location of the Context? Or is it possible that it was missed and it now points to garbage? Thanks, matt On Thu, Jun 17, 2010 at 1:00 PM, Anton Muhin <[email protected]> wrote: > Yes. Context is roughly an array of pointers to other v8 object. GC > is smart enough to update all the pointers when objects are moved. > > yours, > anton. > > On Thu, Jun 17, 2010 at 8:52 PM, Matt Seegmiller <[email protected]> wrote: >> A follow-up question then: >> >> I notice that, for example, a v8::internal::Context has in its memory >> block a pointer to a v8::internal::GlobalObject (it can be accessed >> from v8::internal::Context::global()). This appears to be a direct >> pointer, not a handle. If the GlobalObject is moved, is the GC >> changing this piece of memory in the Context? >> >> Thanks, >> >> matt >> >> On Thu, Jun 17, 2010 at 12:49 PM, Anton Muhin <[email protected]> wrote: >>> Yes. That's exactly the reason why handles are needed. >>> >>> V8 does two moving GCs: scavenge and mark-compact. >>> >>> yours, >>> anton. >>> >>> On Thu, Jun 17, 2010 at 8:28 PM, Matt Seegmiller <[email protected]> wrote: >>>> Am I correct in assuming that the V8 memory allocation and garbage >>>> collection is using movable memory? So, for example, if I have a >>>> handle to a Context and in the course of debugging I dereference down >>>> and get the address of the v8::internal::Context it points at, at a >>>> later point in time, is it possible that if I do the same dereference >>>> I could get a different address for the same v8::internal::Context? >>>> >>>> Thanks, >>>> >>>> matt >>>> >>>> -- >>>> v8-users mailing list >>>> [email protected] >>>> http://groups.google.com/group/v8-users >>>> >>> >>> -- >>> v8-users mailing list >>> [email protected] >>> http://groups.google.com/group/v8-users >> >> -- >> v8-users mailing list >> [email protected] >> http://groups.google.com/group/v8-users >> > > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
