on 07.05.2009 22:25, Maciej Stachowiak at m...@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 performance). > 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. _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
