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.
"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?"
"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.
> 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.
> 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.
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.
> It certainly seems relevant, because Dartium has cross-VM leaks.
Sorry, I must have looked at the wrong message, because reading it now, that's not at all the context I was responding to. However, that message was so late in the thread that are you really surprised it didn't get answered? The conclusion had been reached hours earlier and the broad consensus was clearly to not support multiple run-time VMs in WebKit.
> 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,
Mozilla has had support for multiple VM bindings for as long as I can remember. I know at least ActiveState has shipped products based on it. So, it strikes me as very dubious for you to argue like this is some sort of fundamentally intractable problem.
> as evidenced by that webkit-dev thread
It seems like you read a tremendous amount a late response to a concluded thread.
>as well as conversations I have been a part of or witnessed since Dartium was announced.
Forgive me, but you haven't cited any of those.
> 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.
To be honest, I don't really know what Dart is doing beyond what shows up on mailing lists. It's not part of Chromium so it's not a pressing concern for me. I have had involvement with the team working on Oilpan, because it's a Chromium project and it looks like it could help address object lifetime issues, which are a major security concern. And regardless of anything that may or may not happen with Dart, the outcome of Oilpan is very important for Chromium and V8.
The whole first half of that presentation enumerates the issues with V8's current GC. So, are you really still disputing that the primary purpose of Oilpan is to address issues in V8's GC?
> 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.
One statement implies that there's some fundamental incompatibility affecting any design. The other implies implementation details that need to be resolved. I think an objective observer would find that the distinction between the two is very important.
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/...
[2] https://groups.google.com/a/chromium.org/forum/#!topic/blink...