[webkit-dev] MessagePorts and garbage collection

[Drew Wilson]

Sorry - what I meant by "not a multi-thread" issue was that it's really a
multi-heap issue. The fact that each heap is GC'd on different threads
doesn't seem to make the problem significantly harder, but I could be wrong
- it was kind of a throwaway comment anyway.

Anyhow, I agree with your conclusion - I've been going down the same design
path (separate data structure shared by both sides which can track pending
messages on both ends).

An unreachable MessagePort can become reachable as you say - by having its
onmessage handler stuff the pointer somewhere, so any message port with any
message en-route to either side should be treated as reachable. This isn't
hard to do with the shared state - the only missing piece is the ability to
detect when there are no references, which isn't currently possible.

The code in JSC::Protect.h is almost what we want. There are only two things
that would need to change:

1) Change Heap::collect() to invoke markProtectedObjects() later in the GC
cycle (after marking the call frames)
2) Change markProtectedObjects() to invoke some function on the object (i.e.
"markProtected()") prior to calling mark():

    ProtectCountSet::iterator end = m_protectedValues.end();
    for (ProtectCountSet::iterator it = m_protectedValues.begin(); it !=
end; ++it) {
        JSCell* val = it->first;
        if (!val->marked())
*            val->markProtected();*
            val->mark();
    }

This would allow protected objects to know that they were being kept alive
solely due to gcProtect(), not via references. Then we could use that to
track common state and when we know the MessagePort is completely
unreachable/idle, we can unprotect both ends to allow them to be GC'd.

The alternative is to not leverage protect() but instead to add a separate
set which essentially acts like the protected set but with the different
behavior above.

The advantage of having the separate set is it seems like it has a lower
performance impact, as the number of objects in the new protected set will
be much lower than the number of overall gcProtect()-ed objects. The
downside is that it's really very similar functionality, so the conceptual
burden of having both is higher.

I'll propose the latter in my design (new separate protected set) if nobody
has a strong preference for changing the behavior of the current protect()
set.

-atw






2009/5/7 Maciej Stachowiak <mjs at apple.com>

>
> On May 6, 2009, at 6:41 PM, Drew Wilson wrote:
>
> Following up. I think I have my head around how Worker GC is happening (I
> may start another thread about that, as it looks like there's some cases
> where the thread won't be shut down, but the general design is sound).
>
> MessagePort GC is a little trickier, because we need to detect when both
> sides have no external references, based on this part of the HTML5 spec:
>
>> [...] a message port can be received, given an event listener, and then
>> forgotten, and so long as that event listener could receive a message, the
>> channel will be maintained.
>>
>> Of course, if this was to occur on both sides of the channel, then both
>> ports would be garbage collected, since they would not be reachable from
>> live code, despite having a strong reference to each other.
>>
> From looking at the code in bindings/js, it looks like I've got two tools
> to manage object reachability:
>
> 1) I can tell when my object is reachable (during a GC) because mark() will
> be invoked on it.
> 2) I can force my object to stay active (as long as the owning context is
> active) by making it an ActiveDOMObject and returning true from
> hasPendingActivity() (which seems like it does nothing but invoke mark() on
> the object).
>
> So, #2 lets me keep an object alive, but to implement the spec, I need to
> be able to detect when my object has no more references, without actually
> having it get garbage collected. If I can do that, then I can build my own
> distributed state mechanism to allow me to determine when it's safe to GC
> the objects.
>
> I'm looking through the JSC::Collector code, and I didn't see anything that
> did exactly what I want, but there are probably some things that we could do
> with protect() to enable this. Has anyone else had to do anything like what
> I describe above? It's not exactly even a multi-thread issue, as it seems
> like this problem would occur even with just a single thread.
>
>
> It is specifically a multi-thread issue, because with a single thread and
> single heap both MessagePorts could just mark() each other - if they have no
> other references, they will be collected anyway because GC will happily
> collect an unreferenced cycle.
>
> It's only the separate per-thread heaps that make it challenging, since GC
> may occur at different times and on separate heaps, so the two MessagePorts
> have to protect each other in a persistent way until both become
> unreachable.
>
> The best way I can think of to handle this is to have a special phase after
> normal marking where objects with an external/cross-thread reference get
> marked in a distinctive way. Then each MessagePort would know if it was
> marked solely due to its opposite endpoint being live. I don't recall if
> there is a way for an unreachable MessagePort to become reachable - I think
> yes, because the message event listener can stuff the MessagePort in a
> global variable. But I think an unerachable port can only become reachable
> by receiving a message. Thus, you need a core data structure for the
> MessageChannel which detects the case that there are no messages pending in
> either direct and both endpoints are alive only due to the other endpoint.
> Something like that. This is a very rough design sketch, Alexey can probably
> explain in more detail or I can study the code.
>
> My impression is that Workers use a similar scheme with a special
> additional marking phase, or once did, but Alexey will recall better than I.
>
>  - Maciej
>
>
>
>
> -atw
>
> 2009/5/6 Drew Wilson <atwilson at google.com>
>
>> Thanks, this puts me on the right track. I've had a bunch of discussions
>> with the Chrome folks on how we'd track MessagePort reachability in Chrome,
>> but I'd hoped that the problem might be simpler in WebKit since we had
>> direct access to the data structures cross-thread. The existence of separate
>> GC heaps means it's not particularly simpler after all.
>>
>> -atw
>>
>> 2009/5/6 Maciej Stachowiak <mjs at apple.com>
>>
>>
>>> On May 6, 2009, at 1:53 PM, Drew Wilson wrote:
>>>
>>> OK, that's good to know (it only supports document contexts) - clearly
>>> some work has been done to prepare for multi-thread usage (for example, the
>>> core data structure is a thread-safe MessageQueue).
>>>
>>> I'm quite happy to drive this design (in fact, I'm in the middle of this
>>> now) but I would like to make sure I understand in general what the correct
>>> approach is for managing GC-able objects that are accessed cross-thread - I
>>> haven't been able to find any documentation (outside of the code itself).
>>>
>>> Is the right approach to use JSLock when manipulating cross-thread
>>> linkage? I'll write up a quick document to describe the approach I'm taking,
>>> but I'd like to understand your concerns about deadlocks. So long as we have
>>> only a single shared per-channel mutex, and we never grab any other locks
>>> (like JSLock) after grabbing that mutex, we should be OK. Are there other
>>> locks that may be grabbed behind the scenes that I should be aware of?
>>>
>>>
>>>
>>> JSLock is not the right approach. Workers have their own completely
>>> separate GC heap. JSLock only locks the current context group's heap. It
>>> will not prevent collection in other heaps.
>>>
>>> I don't know exactly what the right approach is. Ultimately it's a
>>> distributed GC problem, both for our split-heap multithreading and for an
>>> approach that used processes for workers. And distributed GC is hard.
>>>
>>> However, Worker itself has a similar issue, since it can be kept alive
>>> either from the inside or the outside reference. You could look at how that
>>> problem was solved.
>>>
>>>  - Maciej
>>>
>>>
>>>
>>> -atw
>>>
>>> 2009/5/6 Alexey Proskuryakov <ap at webkit.org>
>>>
>>>>
>>>> 06.05.2009, в 21:38, Drew Wilson написал(а):
>>>>
>>>>  It looks like the JSC collection code relies on JSLock to lock the heap
>>>>> - I'm guessing that I'll need to explicitly grab the JSLock whenever I'm
>>>>> manipulating the linkage between the two ports, is that correct? Or is there
>>>>> a different/better way to handle situations like this?
>>>>>
>>>>
>>>>
>>>> The JavaScriptCore implementation of MessagePorts only supports document
>>>> contexts (i.e., it only works on main thread).
>>>>
>>>> As mentioned earlier, the first thing needed to implement MessagePorts
>>>> in workers is a design of how they can be passed around without breaking GC.
>>>> It is likely that taking a lock whenever atomicity is desired will cause
>>>> deadlocks.
>>>>
>>>> - WBR, Alexey Proskuryakov
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090507/bae2d9d9/attachment.html>