Very good to know, thanks a lot for investigation, Matt. yours, anton.
On Fri, Jun 18, 2010 at 12:37 AM, Matt Seegmiller <[email protected]> wrote: > 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 > -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
