4 ms·

You are very, very confused and your comment is wholly untrue. Dart uses the normal binding layer (with refcounted object handles) in their Dartium branch, and

You are very, very confused and your comment is wholly untrue. Dart uses the normal binding layer (with refcounted object handles) in their Dartium branch, and the patch to add support to WebKit/Blink is quite tractable, both prior to and after the Blink fork. The largest changes introduced are dynamic language selection and another language binding target. Members of the WebKit project objected to accepting the original patch over concerns of: the increased burden of supporting another target binding; negative performance impacts from another layer of indirection due to run-time selection rather than compile-time; and whether such experimental feature work aligned with the WebKit project goals [1]. Oilpan is an wholly unrelated project that's investigating moving some of the DOM lifetime management over to GC rather than it's current reference counted structure [2]. It will have to integrate with any language engine, of course, but the work is being done as part of Blink and V8, not Dart. The impetus for the project is to address various recurring issues including: memory consumption, GC performance, object lifetime bugs, and general code readability. [1] https://lists.webkit.org/pipermail/webkit-dev/2011-December/018775.html https://lists.webkit.org/pipermail/webkit-dev/2011-December/... [2] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/qI5KrH1QAx8 https://groups.google.com/a/chromium.org/forum/#!topic/blink...

pcwalton 13y ago
I'm referring to Filip Pizlo's message regarding the cross-heap GC issues that were raised on webkit-dev (which is part of the thread you linked): https://lists.webkit.org/pipermail/webkit-dev/2011-December/018811.html https://lists.webkit.org/pipermail/webkit-dev/2011-December/... "You'll need to make sure that the different GCs can coordinate, which will induce overhead. Otherwise you will either not have an story of object reclamation, or you'll have memory leaks. It's just sufficient if one program, in one language, can reference a window containing code written in a different language. Doing this right is hard. See either Wegiel and Krintz OOPSLA'10 or Pizlo, Hosking, and Vitek LCTES'07 for studies of prior attempts to have interoperability between independent GCs. Both seem to indicate >5% throughput regression. Are you claiming that a 5% throughput regression is worth it to support a new language, that is not an open standard, and currently has nonexistent adoption?" There were no replies from Chromium's side. My information regarding Oilpan was based on Justin Fagnani's message in this thread: https://groups.google.com/a/dartlang.org/forum/#!msg/misc/ymUrZT_e5Yc/fw1n35o4FTAJ https://groups.google.com/a/dartlang.org/forum/#!msg/misc/ym... "We're hoping to not have to re-introduce scopes, since in dart2js we don't have a memory leak, and Dartium will be able to collect cycles across heaps when Oilpan lands. This would mean that there are leaks in Dartium until Oilpan, but that's similar to the leaks that GWT-Exporter has, which I've seen go into production with no problems, so I'm hoping it's manageable." Here's how I interpret the situation: Cross-VM memory leaks are a blocker for shipping in any browser; you cannot reasonably say the implementation is done if it is leaky (on this I assume we agree). Dartium currently has cross-VM memory leaks ("cycles across heaps" as above). Upstream WebKit raised issues regarding the performance cost of collecting cross-VM cycles, which Dartium currently does not do. Chromium's plan to mitigate this seems to be Oilpan. This is fine—it's the most logical response!—but doing the same in other browsers is going to be a huge burden, since all browsers use reference-counted DOM handles. If things have changed since then, please let me know and I will happily correct my post.
- justinschuh 13y ago
  > I'm referring to Filip Pizlo's message regarding the cross-heap GC issues that were raised on webkit-dev (which is part of the thread you linked): I assume no one replied because the argument was a broad generalization that wasn't relevant to the proposed patches or the actual code under discussion. Did you bother to look at the actual code? >There were no replies from Chromium's side. You seem to be conflating the members of the Dart project with the members of the Chromium project. The only responses I see from Chromium developers on that thread are from active WebKit contributors who are simply clarifying a few technical details. The multi-VM patch itself was clearly proposed and being argued for by members of the Dart project, not the Chromium project. >If things have changed since then, please let me know and I will happily correct my post. I'm not sure if this is trolling, or if you're actually serious. You outright flamed about how invasive Dart is and that Chrome's DOM is being rewritten just to support it (which it clearly is not). And your sole supporting evidence is two engineers discussing how an implementation detail of Dart would change if Oilpan lands. So, is that really your argument, that an engineer being aware of a highly relevant, potential change discussed a few weeks earlier on a public mailing list must somehow mean that his team is forcing it to possibly happen at some unknown point in the future? I mean, the Dart leads were explicitly CC'd on the Oilpan announcement, and I'm sure the teams do communicate at least occasionally. So, I would hope that Dart engineers would be aware of the potential impacts. And he even expressed it as a hope, with the rest of the context making it pretty clear that he was prepared to re-introduce scopes if Oilpan didn't work out or arrive in time. Thinking about it, your citation does an even better job than mine of demonstrating that Dart isn't in any way dependent on Oilpan.
  - pcwalton 13y ago
    > I assume no one replied because the argument was a broad generalization that wasn't relevant to the proposed patches or the actual code under discussion. Did you bother to look at the actual code? It certainly seems relevant, because Dartium has cross-VM leaks. > I'm not sure if this is trolling, or if you're actually serious. You outright flamed about how invasive Dart is and that Chrome's DOM is being rewritten just to support it (which it clearly is not). I am sorry that you interpreted my concerns as flaming or trolling. My point is quite simply that the cross-VM garbage collection story is one of the chief concerns that other browser manufacturers have with Dart, as evidenced by that webkit-dev thread as well as conversations I have been a part of or witnessed since Dartium was announced. As of the time that message was sent the Chromium story has been Oilpan, and that does not assuage this concern. An alternative story from Dart's side that could be demonstrated to prevent DOM leaks in a reference-counted DOM world would go a long way here, but it does not seem that Dart is currently taking this into consideration. I hope you will forgive me for not wanting to escalate this back-and-forth further. Edit: I was pointed by a colleague to this presentation by Lars Bak which confirms this. Page 44: http://commondatastorage.googleapis.com/io-2013/presentations/209%20-%20fast-code-is-always-in-fashion.pdf http://commondatastorage.googleapis.com/io-2013/presentation... According to him, the Dart VM causes leaks: "Impossible to guarantee unused objects are reclaimed; this implies memory leaks", and Oilpan is presented on the next page as the solution. Edit 2: Another colleague of mine pointed out that I said "memory model" when I should have said "memory management implementation". Apologies for being inaccurate there.

pcwalton 13y ago

I'm referring to Filip Pizlo's message regarding the cross-heap GC issues that were raised on webkit-dev (which is part of the thread you linked): https://lists.webkit.org/pipermail/webkit-dev/2011-December/018811.html https://lists.webkit.org/pipermail/webkit-dev/2011-December/... "You'll need to make sure that the different GCs can coordinate, which will induce overhead. Otherwise you will either not have an story of object reclamation, or you'll have memory leaks. It's just sufficient if one program, in one language, can reference a window containing code written in a different language. Doing this right is hard. See either Wegiel and Krintz OOPSLA'10 or Pizlo, Hosking, and Vitek LCTES'07 for studies of prior attempts to have interoperability between independent GCs. Both seem to indicate >5% throughput regression. Are you claiming that a 5% throughput regression is worth it to support a new language, that is not an open standard, and currently has nonexistent adoption?" There were no replies from Chromium's side. My information regarding Oilpan was based on Justin Fagnani's message in this thread: https://groups.google.com/a/dartlang.org/forum/#!msg/misc/ymUrZT_e5Yc/fw1n35o4FTAJ https://groups.google.com/a/dartlang.org/forum/#!msg/misc/ym... "We're hoping to not have to re-introduce scopes, since in dart2js we don't have a memory leak, and Dartium will be able to collect cycles across heaps when Oilpan lands. This would mean that there are leaks in Dartium until Oilpan, but that's similar to the leaks that GWT-Exporter has, which I've seen go into production with no problems, so I'm hoping it's manageable." Here's how I interpret the situation: Cross-VM memory leaks are a blocker for shipping in any browser; you cannot reasonably say the implementation is done if it is leaky (on this I assume we agree). Dartium currently has cross-VM memory leaks ("cycles across heaps" as above). Upstream WebKit raised issues regarding the performance cost of collecting cross-VM cycles, which Dartium currently does not do. Chromium's plan to mitigate this seems to be Oilpan. This is fine—it's the most logical response!—but doing the same in other browsers is going to be a huge burden, since all browsers use reference-counted DOM handles. If things have changed since then, please let me know and I will happily correct my post.

justinschuh 13y ago
> I'm referring to Filip Pizlo's message regarding the cross-heap GC issues that were raised on webkit-dev (which is part of the thread you linked): I assume no one replied because the argument was a broad generalization that wasn't relevant to the proposed patches or the actual code under discussion. Did you bother to look at the actual code? >There were no replies from Chromium's side. You seem to be conflating the members of the Dart project with the members of the Chromium project. The only responses I see from Chromium developers on that thread are from active WebKit contributors who are simply clarifying a few technical details. The multi-VM patch itself was clearly proposed and being argued for by members of the Dart project, not the Chromium project. >If things have changed since then, please let me know and I will happily correct my post. I'm not sure if this is trolling, or if you're actually serious. You outright flamed about how invasive Dart is and that Chrome's DOM is being rewritten just to support it (which it clearly is not). And your sole supporting evidence is two engineers discussing how an implementation detail of Dart would change if Oilpan lands. So, is that really your argument, that an engineer being aware of a highly relevant, potential change discussed a few weeks earlier on a public mailing list must somehow mean that his team is forcing it to possibly happen at some unknown point in the future? I mean, the Dart leads were explicitly CC'd on the Oilpan announcement, and I'm sure the teams do communicate at least occasionally. So, I would hope that Dart engineers would be aware of the potential impacts. And he even expressed it as a hope, with the rest of the context making it pretty clear that he was prepared to re-introduce scopes if Oilpan didn't work out or arrive in time. Thinking about it, your citation does an even better job than mine of demonstrating that Dart isn't in any way dependent on Oilpan.
- pcwalton 13y ago
  > I assume no one replied because the argument was a broad generalization that wasn't relevant to the proposed patches or the actual code under discussion. Did you bother to look at the actual code? It certainly seems relevant, because Dartium has cross-VM leaks. > I'm not sure if this is trolling, or if you're actually serious. You outright flamed about how invasive Dart is and that Chrome's DOM is being rewritten just to support it (which it clearly is not). I am sorry that you interpreted my concerns as flaming or trolling. My point is quite simply that the cross-VM garbage collection story is one of the chief concerns that other browser manufacturers have with Dart, as evidenced by that webkit-dev thread as well as conversations I have been a part of or witnessed since Dartium was announced. As of the time that message was sent the Chromium story has been Oilpan, and that does not assuage this concern. An alternative story from Dart's side that could be demonstrated to prevent DOM leaks in a reference-counted DOM world would go a long way here, but it does not seem that Dart is currently taking this into consideration. I hope you will forgive me for not wanting to escalate this back-and-forth further. Edit: I was pointed by a colleague to this presentation by Lars Bak which confirms this. Page 44: http://commondatastorage.googleapis.com/io-2013/presentations/209%20-%20fast-code-is-always-in-fashion.pdf http://commondatastorage.googleapis.com/io-2013/presentation... According to him, the Dart VM causes leaks: "Impossible to guarantee unused objects are reclaimed; this implies memory leaks", and Oilpan is presented on the next page as the solution. Edit 2: Another colleague of mine pointed out that I said "memory model" when I should have said "memory management implementation". Apologies for being inaccurate there.