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.
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/...