[webkit-dev] MessagePorts and garbage collection

Alexey Proskuryakov ap at webkit.org
Thu May 7 11:54:21 PDT 2009

on 07.05.2009 22:25, Maciej Stachowiak at mjs at apple.com wrote:

> 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.

This design with a separate stage between marking and sweeping is something
that I started implementing, and had in ToT for a while last year. As I
recall, the big problem with it is the need to detect when there are no
messages pending in either direction, which is not possible without
temporarily freezing the other thread/process AFAICT. That's something I'd
like to avoid (yes, we do have a lock in MessageQueue, but it's not strictly
necessary long-term, and there are already reports that it seriously affects

> 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.

You are probably thinking about my attempts to implement cross-thread
MessagePort here. Worker GC makes use of the ActiveDOMObject concept - for
as long as there is an unanswered message, or if it is known that the worker
thread has timers (or network requests) running in it, the Worker object in
main thread is deemed uncollectable. So, dedicated workers did not require
any changes to JavaScriptCore GC behavior.

- WBR, Alexey Proskuryakov.

More information about the webkit-dev mailing list