It appears to be safe. I had a pretty consistent case in our game engine that was actually moving a Context during an Unlocker. I changed the code to always start a separate thread, instantiate a Locker, and change the top Context once locked to ensure that the Context was archived and then cleared.
When the Context was moved while archived by the Unlocker, it came back correctly when the Unlocker restored the thread. So it looks the answer to my question is that the ThreadState's archived pointers do get updated when objects they point to are moved by the GC. matt On Thu, Jun 17, 2010 at 2:03 PM, Anton Muhin <[email protected]> wrote: > You can use v8::internal::Heap::CollectAllGarbage method. > > I'd suggest to do something like that: allocate a lot of objects, but > keep them referenced in a chain: obj1 refs obj2 refs obj3 .... refs > objn. Then remove the only reference to obj1 and force GC. The trick > could be to make Context pointer to move though. > > yours, > anton. > > On Thu, Jun 17, 2010 at 9:57 PM, Matt Seegmiller <[email protected]> wrote: >> I'd be happy to try, because if the situation I described is >> happening, it could definitely be causing a very sporadic yet >> consistent crash we've been having. One question, though, how could I >> force the garbage collector to run, let alone force the garbage >> collector to move some specific object when it does? >> >> Thanks, >> >> matt >> >> On Thu, Jun 17, 2010 at 1:46 PM, Anton Muhin <[email protected]> wrote: >>> 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 >> >> -- >> 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
