[webkit-dev] MessagePorts and garbage collection

[Drew Wilson]

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/20090506/5b3585a0/attachment.html>