I don't know from top of my head, sorry. If you could make a failing test case (your scenario seems rather ease to turn into a test), v8 team would be most obliged :)
yours, anton. On Thu, Jun 17, 2010 at 9:16 PM, Matt Seegmiller <[email protected]> wrote: > 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 > -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
