5 ms·

This seems overly negative, and for rather simplistic reasons. If Dart is successful internally, I'm sure they'll keep working on it. Making their developers' l

This seems overly negative, and for rather simplistic reasons. If Dart is successful internally, I'm sure they'll keep working on it. Making their developers' lives easier, and making their web properties faster/better is easily worth it for them. Also, your edit doesn't strike me as evil. It's only evil if they prevent other vendors from putting in a Dart VM. The language is opensource, and so is Chromium where their VM implementation would be, so that seems unlikely. They'd have to put in quirks that make it "work best" on Chrome that they somehow hide from the competition. I mean, was SPDY an evil move? It was originally baked into Chrome but the spec and implementation were open. It just took Firefox and others longer to decide to add support.

pcwalton 13y ago
The DOM memory model that all browsers use is incompatible with Dart (or any "second language" for the Web). That includes Chrome, by the way: that's why they need the Oilpan project which completely rewrites DOM memory management from scratch. In practice this is going to be a blocker for other engines to "just adopt" the Dart VM. (These concerns were raised, and ignored, on webkit-dev when Google first proposed Dart support.)
- magicalist 13y ago
  This seems like a weirdly combative comment. This certainly isn't the primary technical (or emotional) argument against Dart. To translate for others: browsers tied the DOM memory model tightly to the single Javascript VM because it was a lot easier that way, and expanding support to multiple VMs will take a lot of work. This is one reason why you don't see many browser forks running with the "let's just add python to browsers" idea that so many have had. It's also why we still have no canvas or WebGL in web workers: no one has a DOM that sufficiently supports multi-threaded access. I have no idea what "ignored" means in this context, since Dart bindings obviously weren't added to webkit, and Oilpan is replacing the GC model for the DOM in blink. That might make it easier to support Dart (that's still only something I've read here on HN, but I don't follow Dart lists), but it's a performance improvement that has long been needed. Try tracing garbage collection in Chrome sometime in an app that manipulates the DOM; the typical pause will spend most of its time trying to collect memory on the DOM side, not the Javascript side, even for some of the simplest DOM manipulations. My understanding is that (somewhat humorously, in the context of the above) this is because of the more inefficient bindings created to allow V8 to work with Webkit, where it used to be that only JavaScriptCore bindings were needed.
  - pcwalton 13y ago
    It's not just that expanding support for the DOM memory model to support multiple VMs is a lot of work, it's that it's a lot of work that is totally unnecessary unless you want to add multiple languages to the Web, which is a problem that the other browser manufacturers don't want to solve. In other words: the lack of support for multiple languages in the DOM is not a drawback of browser engines; rather it's a drawback of the Dart VM. This is much of the reason behind the objections that were raised on webkit-dev. Having suboptimal GC performance in the DOM can be solved in other ways: for example, the cycle collector that Gecko uses. (That said, Servo [full disclosure: I'm a Servo core team member] is pursuing a more Oilpan-like approach, but not to support multiple languages.)
    - magicalist 13y ago
      Yes, the design of browsers requires a lot of work to integrate any second VM, which is what I said. The objections that were raised on webkit-dev were that that work had to be justified by proven gains (e.g. developers will actually use added languages) and proven lack of regressions caused by the new bindings[1]. These were the same objections raised when upstreaming the V8 bindings happened, as well, btw and are exactly correct. As for DOM GC performance, yes, it could be solved in other ways, or you could move it to the same GC-able heap as the language manipulating it. I'm still not seeing the connection to Dart, but, again, maybe I'm just out of the Dart loop (some simple searches haven't revealed much beyond the blink-dev list and associated code reviews). AFAIK oilpan is coming out of long-time work by haraken et al in webkit and now blink to bring huge performance improvements to the V8/browser bindings, which have historically been much slower relative to other browsers and their javascript engines. [1] https://lists.webkit.org/pipermail/webkit-dev/2011-December/018811.html https://lists.webkit.org/pipermail/webkit-dev/2011-December/...
- justinschuh 13y ago
  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.

pcwalton 13y ago

The DOM memory model that all browsers use is incompatible with Dart (or any "second language" for the Web). That includes Chrome, by the way: that's why they need the Oilpan project which completely rewrites DOM memory management from scratch. In practice this is going to be a blocker for other engines to "just adopt" the Dart VM. (These concerns were raised, and ignored, on webkit-dev when Google first proposed Dart support.)

magicalist 13y ago
This seems like a weirdly combative comment. This certainly isn't the primary technical (or emotional) argument against Dart. To translate for others: browsers tied the DOM memory model tightly to the single Javascript VM because it was a lot easier that way, and expanding support to multiple VMs will take a lot of work. This is one reason why you don't see many browser forks running with the "let's just add python to browsers" idea that so many have had. It's also why we still have no canvas or WebGL in web workers: no one has a DOM that sufficiently supports multi-threaded access. I have no idea what "ignored" means in this context, since Dart bindings obviously weren't added to webkit, and Oilpan is replacing the GC model for the DOM in blink. That might make it easier to support Dart (that's still only something I've read here on HN, but I don't follow Dart lists), but it's a performance improvement that has long been needed. Try tracing garbage collection in Chrome sometime in an app that manipulates the DOM; the typical pause will spend most of its time trying to collect memory on the DOM side, not the Javascript side, even for some of the simplest DOM manipulations. My understanding is that (somewhat humorously, in the context of the above) this is because of the more inefficient bindings created to allow V8 to work with Webkit, where it used to be that only JavaScriptCore bindings were needed.
- pcwalton 13y ago
  It's not just that expanding support for the DOM memory model to support multiple VMs is a lot of work, it's that it's a lot of work that is totally unnecessary unless you want to add multiple languages to the Web, which is a problem that the other browser manufacturers don't want to solve. In other words: the lack of support for multiple languages in the DOM is not a drawback of browser engines; rather it's a drawback of the Dart VM. This is much of the reason behind the objections that were raised on webkit-dev. Having suboptimal GC performance in the DOM can be solved in other ways: for example, the cycle collector that Gecko uses. (That said, Servo [full disclosure: I'm a Servo core team member] is pursuing a more Oilpan-like approach, but not to support multiple languages.)
  - magicalist 13y ago
    Yes, the design of browsers requires a lot of work to integrate any second VM, which is what I said. The objections that were raised on webkit-dev were that that work had to be justified by proven gains (e.g. developers will actually use added languages) and proven lack of regressions caused by the new bindings[1]. These were the same objections raised when upstreaming the V8 bindings happened, as well, btw and are exactly correct. As for DOM GC performance, yes, it could be solved in other ways, or you could move it to the same GC-able heap as the language manipulating it. I'm still not seeing the connection to Dart, but, again, maybe I'm just out of the Dart loop (some simple searches haven't revealed much beyond the blink-dev list and associated code reviews). AFAIK oilpan is coming out of long-time work by haraken et al in webkit and now blink to bring huge performance improvements to the V8/browser bindings, which have historically been much slower relative to other browsers and their javascript engines. [1] https://lists.webkit.org/pipermail/webkit-dev/2011-December/018811.html https://lists.webkit.org/pipermail/webkit-dev/2011-December/...
justinschuh 13y ago
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.