On Tue, Dec 11, 2018 at 11:13 AM Michael Lippautz <mlippa...@chromium.org>
wrote:
> I really hope that handles are only access from the same thread the GC is
> running on. Otherwise, you would need a v8::Locker to synchronize that
> access.
>
Right, the isolate mutex is locked any time we're manipulating handles.
> Also, you are marking *all* handles with MarkActive()? That should
> essentially make all of the handles strong for the Scavenger.
>
Yes, because the scavenger doesn't trace objects with EmbedderHeapTracer, I
think we have to mark all handles active (as visited
via VisitWeakHandles()).
> That contradicts with the crash happening
> after IterateNewSpaceWeakUnmodifiedRootsForPhantomHandles which deals with
> weak handles that are not marked as active. (Assuming you did not use
> MarkIndependent()).
>
There is a version of my change which uses MarkIndependent() when we know
that there are *no* references from C++ objects (i.e. when the handle
exists purely to register the weak callback to delete the object). However,
I still observe this crash even when I comment out the call to
MarkIndependent().
I agree that this seems inconsistent.
> I don't expect you to be able to figure this out for me, but do you have
>> any hints for debugging strategies I should try?
>>
>
> Essentially, it looks like you are scavenging a root node twice, which is
> why you already see it in ToSpace when it's getting added through the
> visitor.
>
> The relevant functions are in src/global-handles.{h,cc} and called
> throughout scavenging in this order:
> 1. IdentifyWeakUnmodifiedObjects
> <https://cs.chromium.org/chromium/src/v8/src/global-handles.cc?q=IdentifyWeakUnmodifiedObjects&sq=package:chromium&g=0&l=673>:
> Makes nodes active that V8 thinks should be active in addition to those
> that already had MarkActive() called on them.
> 2. IterateNewSpaceStrongAndDependentRoots
> <https://cs.chromium.org/chromium/src/v8/src/global-handles.cc?type=cs&q=IterateNewSpaceStrongAndDependentRoots&sq=package:chromium&g=0&l=646>:
> Scavenges strong handles and those that are active.
> 3. MarkNewSpaceWeakUnmodifiedObjectsPending
> <https://cs.chromium.org/chromium/src/v8/src/global-handles.cc?type=cs&q=MarkNewSpaceWeakUnmodifiedObjectsPending&sq=package:chromium&g=0&l=682>:
> Identifies nodes that require finalizers.
> 4. IterateNewSpaceWeakUnmodifiedRootsForFinalizers
> <https://cs.chromium.org/chromium/src/v8/src/global-handles.cc?type=cs&q=IterateNewSpaceWeakUnmodifiedRootsForFinalizers&sq=package:chromium&g=0&l=695>:
> Scavengers nodes that require finalizers.
> 5. IterateNewSpaceWeakUnmodifiedRootsForPhantomHandles
> <https://cs.chromium.org/chromium/src/v8/src/global-handles.cc?type=cs&q=IterateNewSpaceWeakUnmodifiedRootsForPhantomHandles&sq=package:chromium&g=0&l=710>:
> Resets weak handles or scavenges them. Scavenging here just means updating
> the forwarding pointer from FromSpace to ToSpace as the object itself has
> already been scavenged if we don't need to reset it.
>
> The sets of handles that are scavenged should be disjoint in 2), 4) and
> 5). Whenever a node is already pointing directly to ToSpace that should be
> a bug and some other method probably scavenged it in the same run before.
>
> The interesting part is then why multiple methods match the same node for
> scavenging.
>
Thanks, I think this helps. I'll do some more digging.
-Kenton
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
