Comment by gsnedders | Hacker News Reader

Comment by gsnedders | Hacker News Reader

Parent Full thread

> - It puts all DOM objects in the JS heap, eliminating the nightmarish cross-heap reference counting that historically plagues browser architectures (this is part of Blink's "oilpan" architecture).

Does Gecko not already do this? Certainly Presto did, and (I believe) Trident does.

But to add another bit of research into the mix, and what I think is arguably the most important point:

- Builds on all the work around HTML(5) and CSS 2.1, both of which are the best part of a decade of work, both aiming to get browsers actually implementing to specifications, and specifying behaviour in sufficient detail (with minimal undefined behaviour) that a web page cannot easily distinguish two user agents. By actually specifying the web platform as it actually exists, it suddenly makes it far more practical for new browsers to enter the market (compared with the previous hellish situation of the hardest part of developing a browser being reverse-engineering existing browsers with sufficient marketshare that web developers ensure their web pages work in them). If this is shown to be viable, suddenly we have a truly open platform!

Here's another really fantastic reason for the research Servo is doing: by using concurrency and parallelism pervasively, Servo is discovering and mapping out all the places where sequentialism is baked into the web standards themselves. With any luck, their experiences will help to guide the next generation of web standards and prevent them from being inadvertently hostile to parallelism.

This is certainly part of the intent, and it has already started to happen in some limited ways. For example, Bobby Holley noticed that certain document.domain changes could make implementing parallelism hard and worked to address this in the spec.

I've been following Servo for a long time and had never begun to consider this. How incredibly exciting it is that they could actually get to the point where the only thing holding back their performance wasn't even in the code.

floats :(

The float taketh away and the clear: both giveth back again:

http://pcwalton.github.io/blog/2014/02/25/revamped-parallel-...

DOM objects are reference counted in Gecko, and there is a cycle collector to collect JS/C++ cycles. They aren't allocated in the JS heap.

WebKit is similar, but without the cycle collector.

Ah — I'd presumed since you detected cycles that it was in the GC'd JS heap, as opposed to having a separate cycle collector.

The main improvement that Servo's architecture brings over things like Oilpan (and, it sounds like, some other browser engines too) is that our GC is single-threaded, despite the browser itself being highly multithreaded, and it's precise instead of conservative. (Well, to be more exact, it will be precise when we upgrade our copy of SpiderMonkey. Also note that Oilpan is only mostly conservative, in that it can do precise collections if no C++ is on the stack.)

Single-threaded GC is nice because it doesn't have to stop any other threads in order to run; it also tends to reduce the size of the heap that must be scanned. For example, while script is collecting garbage, the layout and painting threads can run unimpeded. Of course, using a single-threaded GC in a multithreaded app means you have to be extremely careful in order to avoid the GC freeing things you don't want to be freed, and that is why it is seldom done. Our trick is to use the Rust type system to enforce that this is done correctly at compile time, which is something that is not possible in C++.

Here is a presentation (and its slides) describing the implementation details of Firefox's cycle collector:

https://air.mozilla.org/gecko-cycle-collector-intro/

http://mozilla.pettay.fi/cycle_collection_optimizations/

> (I believe) Trident does.

I doubt it, Trident's DOM is COM objects. Not only are the heaps separate, the DOM heap is page-independent and in the old days you could leak DOM objects for whole sessions if you created a circular reference between JS and DOM (because you set up an event handler closure for instance, the DOM element would reference the closure and the closure would close over the DOM element). There were tools (Drip and later sIEve) whose sole job was to wrap MSHTML, reload pages and detect objects remaining from the page you'd just left.

You're describing the situation 10 years ago. It's not at all clear whether that still holds today.

Also note, just because objects can have COM-accessible reference doesn't mean they always need to have one. It's quite possible they're just wrappers created on demand.

Trident moved away from using COM for JS/DOM communication with the introduction of Chakra in IE9. I believe as of IE9 they allocate DOM objects as host objects in the JS heap.

> that a web page cannot easily distinguish two user agents.

Don't need to, to be more precise.

Both, really — any vector that can be used to distinguish UAs often is (even very dubious ones — HTMLUnknownElement implying Gecko, for example!), and that's harmful to the open web.

Reply on news.ycombinator.com