
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 29, 2009, at 11:29 AM, Drew Wilson wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div class="gmail_quote">On Thu, May 28, 2009 at 7:47 PM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com">mjs@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im"><br> On May 28, 2009, at 5:17 PM, Ian Hickson wrote:<br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Thu, 28 May 2009, Maciej Stachowiak wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On May 28, 2009, at 1:08 PM, Ian Hickson wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Thu, 28 May 2009, Maciej Stachowiak wrote:<br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> If so, that seems like it could create unbounded memory leaks in<br> long-running Web applications that use MessagePorts, even if all<br> references to both endpoints of the MessageChannel are dropped. That<br> seems unacceptable to me, unless I misunderstood.<br> </blockquote> <br> The requirement is actually indistinguishable from the UA using the<br> other alternative and just having a really slow garbage collector that<br> only runs at page-closing time.<br> </blockquote> <br> So it's exactly equivalent to the old requirement, except the spec now<br> specifically points out that you can just leak forever instead. I don't<br> think that addresses the original concern at all.<br> </blockquote> <br> I've tweaked the text some to make it clear that once the port is not<br> entangled, it doesn't continue being protected in this way.<br> </blockquote> <br></div> The new text seems to be this:<br> <br> "When a MessagePort object is entangled, user agents must either act as if the object has a strong reference to its entangledMessagePort object, or as if the MessagePort object's owner has a strong reference to the MessagePort object"<br> <br> It seems to me this allows the following case: two message ports A and B are entangled. A is treated as having a strong reference to B, but is not treated as if its owner has a strong reference to it. However, B is not treated as having a strong reference to A, but is treated as if its owner has a strong reference to it. Is that intended? I think this behavior would be practically implementable and quite useful in many cases, even though it is asymmetric. But I am not sure if the text intended to allow it.</blockquote> <div><br></div><div>Can you elaborate on this a bit? Where would this asymmetric behavior be useful? It seems like in the specific case you cite, B would be doubly-referenced, while A would be unreferenced.</div></div></blockquote><br></div><div>Ian clarified on IRC that he didn't mean to allow it. The reason it would be useful is that it would allow A to be garbage collected as soon as it has no references, at which point it can notify B that it's gone, and then B can switch rules, and itself be garbage collected once it has no references. It would prevent memory leaks but would not provide meaningful limits on nondeterminism.</div><div><br></div><div>Regards,</div><div>Maciej</div><div><br></div><div>P.S. In case anyone doubts that distributed GC is hard (as apparently Ian did until yesterday), here is a clarifying example. It might seem simple to come up with a protocol for two MessagePorts to tell each other when they are otherwise unreferenced by anything in their own heap with minimal GC hooks. But suppose you have Workers A and B, and Window W, and a MessageChannel connecting each pair. The MessagePorts are AB-A (the endpoint of the AB channel in A), AB-B, AW-A, AW-W, BW-B, BW-W. Now suppose that the two MessagePorts in each global context indirectly reference each other (so AB-A has a reference to AW-W and vice vera and so forth). It's quite hard to come up with a protocol that will let all six MessagePorts know that they have no references besides each other and thus may be garbage collected. Note that this example can easily arise in practice, for example if the onmessage listeners for each message port are closures with both the relevant ports in scope. Note also that distributed GC among 3 heaps is still a much simpler special case than the fully general case of N heaps. In practice, this means that any implementation with split heaps (which likely will include all multiprocess implementations) has to take the more conservative lifetime rule, tying to the owner. So in practice, the only way to reliably free the resources associated with a MessagePort will be to .close() it.</div><div><br></div></body></html>