BTW, it looks like the current Worker implementation doesn't notify the Worker object when timers/network activity are finished, so an unreferenced Worker thread won't be terminated in that case. When I get done with this design mess, I'll log a bug with some tests.
-atw On Thu, May 7, 2009 at 11:54 AM, Alexey Proskuryakov <[email protected]> wrote: > on 07.05.2009 22:25, Maciej Stachowiak at [email protected] 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 [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
