[webkit-dev] MessagePorts and garbage collection

Thu May 7 11:25:11 PDT 2009

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/723cccee/attachment.html>