[the8472]

> The more we fully utilize those cores, the smoother we should be able to make the whole web.

I wonder why the GC/CC are not multithreaded though. It seems like those are fairly isolated components, considering the entire application gets suspended so they can do their job, i.e. prime candidates for parallelism.

When forcing a collection on a large firefox instance it can easily spend 20+ seconds collecting on a single thread while a java VM can munch churn through something like 1 gigabyte per second per core.

In other words, from the outside it looks like a low-hanging fruit that has not been plucked.

[pcwalton]

> I wonder why the GC/CC are not multithreaded though. It seems like those are fairly isolated components, considering the entire application gets suspended so they can do their job, i.e. prime candidates for parallelism.

> When forcing a collection on a large firefox instance it can easily spend 20+ seconds collecting on a single thread while a java VM can munch churn through something like 1 gigabyte per second per core.

Several reasons why this isn't low-hanging fruit and isn't as valuable as it may seem:

1. Servo runs separate origins as fully separated JS VMs on separate threads. Because they're separate runtimes, the collections can already happen concurrently.

2. The isolated JS runtimes imply isolated heaps, so there is no need for global collection (and in fact no way to do it even if we wanted to with the current SpiderMonkey architecture). Small individual per-origin heaps are much faster to collect than large global heaps.

3. While collection is happening, like in other modern browsers, the Servo chrome and scrolling are fully responsive. But Servo goes beyond that: animations, layout, and repainting can also happen while a GC is occurring. This means that CSS transitions/animations on the page (all animations, not just transform and opacity!) will still happen while the page is collecting, and you can switch tabs and resize the window while the GC is running. You can even interact with cross-origin iframes on the page, so GCs triggered by ads won't affect the content you're reading!

4. SpiderMonkey already has incremental and generational GC, so we've done most of the work necessary to reduce stop-the-world pauses already.

5. Making a single-threaded GC concurrent is a lot of work. It's not low-hanging fruit by any stretch of the imagination.

6. Furthermore, making a single-threaded GC concurrent usually involves a throughput loss, because now you need operations to be atomic that weren't atomic before.

That said, the GC is something that the SpiderMonkey team continues to make steady progress on, and that work directly benefits Servo. So fear not, we aren't neglecting the GC either :)

[mccr8]

Writing a parallel GC surely is not "low-hanging fruit" by any reasonable measure. Java already has to deal with concurrency in their objects, and throughput is more of a concern for server-like workloads, so they are dealing with a different situation. In Firefox, most of our effort has focused on improving responsiveness and eliminating work (through things like compartmental GC). (Some GC sweeping is already done in parallel in Firefox.)

That said, I believe IE does some concurrent marking, so there is certainly room for improvement.

[the8472]

> and throughput is more of a concern for server-like workloads

Many java applications also have to worry about latency, not just throughput. Parallel collections cut down on pause times, too. Simply because they can get about the same work (in terms of CPU cycles) done in less wall time. I.e. parallelizing non-concurrent GC phases also improves responsiveness.

[johncolanduoni]

That would be hard to do without writing a new javascript engine, which would expand Servo's current scope pretty dramatically. My guess would be that as long as there are big gains to be made that can be done without rewriting SpiderMonkey, the servo project would rather only tackle one massive project at a time :)