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
