Research
This page is intended to capture some of the open problems currently under investigation, either here or with one of our collaborators.
Under investigation by a group at the University of California, Irvine
We propose taking advantage of the parallel hardware available to us today and the increasing number to be available tomorrow, particularly on mobile processors. But, how much of a performance win can we expect to get?
We'd like to break down top sites. e.g., ala HOTPAR 12, into Javascript, Networking, Windowing/Painting, Parsing, Render, Layout, CSS, and other. This information will allow us to determine which areas of an already-optimized browser still take enough time to be worth attempting to parallelize.
In areas we are trying to parallelize, particularly rendering, layout, and CSS, how much is actually available? Use Work/Span (video slides) parallelism analysis based on looking at the longest sequential dependency chain to both identify (for feedback to page authors) and characterize maximum available speedup.
The general idea is that for any sequential computation, there is a longest chain of sequential dependencies. That chain provides an upper limit on our speedup, as even with an infinite number of processors and no parallel overheads, we still need to evaluate that chain sequentially. By computing these numbers and educating developers on what causes these chains (hopefully graphically!), we hope to inform both what we invest in parallelizing in Servo and developers on the costs of some web platform features.
Under investigation by a groups at the University of California, Irvine and the University of Chicago
Lots of research has already been done on reducing power consumption in browsers, particularly in the mobile space. The pre-fetch tricks for network access are widespread, and at this point power is split evenly display, CPU, radio. How can we reduce CPU further?
How does the power consumption of multiple cores at low freq. compare to one core full-blast? Mobile vs. desktop?
We're encouraging parallelism to speed up page load. But, we shouldn't do that at the expense of power. What are the costs associated with all of this parallelism we're being given?
Under investigation by a group at the University of Colorado, Boulder
There are techniques for avoiding doing the sort of one-up patching of intermediate data structures that is done in every modern web browser to avoid relayout of the entire page when there is only a small modification to the DOM. But, these techniques are quite buggy. Can we use automated techniques to avoid both the bugginess and the one-off handling of specific scenarios as needed by Popular Web Apps?
Under investigation by a group at MPI, Germany
We have Rust in place for many of our memory safety-related issues, particularly use-after-free and single ownership within a set of parallel, concurrent tasks. However, those are not the only type of memory safety issues a browser faces.
Under investigation by groups at the University of Copenhagen + DIKU and CMU
Concurrent programming separates programs into threads of sequential execution that communicate. While this can decouple blocking interactions and improve responsiveness, it can also lead to difficult to understand deadlocks, starvation, and message ordering problems that affect internal state. Here, we are investigating various forms of Session Types to determine alternative approaches.
- Cuckoo hashing for GPUs — http://idav.ucdavis.edu/~dfalcant/research/hashing.php