Skip to content

Prototype ways of splitting the script crate

Jump to bottom
Josh Matthews edited this page Feb 12, 2018 · 3 revisions

Contact: Josh Matthews

The majority of the implementation of Servo's supported DOM APIs and JavaScript integration lives in a single Rust crate - the script crate. When compiling Servo, the large amount of hand-written code is combined with a huge amount of code that is generated during the build process. This causes the build to be quite slow, as well as consume enormous amounts of memory. The goal of this project is to experiment with splitting the script crate up into at least one other crate, by identifying the complex dependencies between modules and prototyping ways to break them. In an ideal world, all of the code that is generated would exist by itself in components/script_codegen/, and all of the hand-written code would exist in components/script/.

Project breakdown

  • Rather than working directly in Servo's code, create a repository with a minimal representative sample that only includes pre-generated and handwritten code. This will allow for more efficient experimentation than rebuilding Servo over and over.
  • Manually apply the ideas described in the github issue to the representative sample
  • Identify any unexpected problems; report benchmarks on memory usage and compilation time
  • Continue expanding the representative sample to include other dependencies that Servo relies on
  • In parallel, using another representative sample that includes code generation, apply the same techniques and figure out how to incorporate them into the code generation that Servo relies upon
  • By the end of the project, create a plan for how the prototypes and experiments could be applied to Servo itself in a meaningful way

Suggestions for preparation

(Feel free to ask questions in #servo on irc.mozilla.org, or our mailing list!)

  • Try to split our sample project to experiment with the techniques you will need to use for this project. Push a branch to github with your changes and include a link with your GSoC application.
  • Learn about the complex dependencies that exist between the code in components/script/dom and other pieces in components/script/.
  • Learn about the relationship between the IDL interfaces in components/script/dom/webidls/ and the Rust implementations in components/script/dom/.
  • Practice splitting one crate into two. Become familiar with using traits to separate the declaration of a data structure from the implementation of methods. Another example.
  • Become familiar with the usage of associated types in traits, which are important for one of the proposed solutions.
  • Read some of the generated code that is created by CodegenRust.py in target/debug/build/script-[hash]/out/Bindings/ and target/debug/build/script-[hash]/out/Bindings/*.rs to better understand the kind of dependencies that currently exist in the generated code.

Important note

The github issue contains a lot of speculation and ideas that have never been attempted at this scale. It is entirely possible that during this project we will end up encountering a problem that cannot be solved! This is still a valuable result, and will not count as a failure of the project or the student. If this ends up happening, we will discuss what to do instead for the remaining time in GSoC so the time is still spent productively.

Clone this wiki locally