How do I get started with V8 development?

Are you interested in understanding more about compilers, virtual machines, JavaScript engines, and maybe even want to contribute to V8?
Have you never taken a compiler course (maybe no formal CS course) or no experience in C++? Fear not, nobody was born with that knowledge. You don’t need to understand all aspects of compilers to make a contribution. Here are some resources that might help you on the way.

There are very few compiler books, and I have not found one that covers modern optimizations, especially for JavaScript engines. If you want to learn the fundamentals, the Dragon Book (Compilers: Principles, Techniques, & Tools, 2nd Edition) is the book to read.

My professor’s copy that he used in grad school. Get the 2nd edition from 2006.

There are multiple blogs about V8:

If you rather listen than read, you might want to watch these videos:

Unfortunately, there’s a huge gap between these high level resources and the actual 948341 lines of source code in V8/src. But you learn by doing. So get the source code and build it. See if you can run the tests. V8 has millions of lines of code in V8/test. Stick to running a few tests locally, or you’ll wait for several hours. Follow the V8 Wiki for building and running V8. The wiki also has instructions on how to commit a change list. A change list is the Chromium terminology for a pull request.

It takes a while to compile V8.

I would suggest you start out very simple. Make a minuscule change in the code, maybe change the wording of an error message. Then compile the code, run it on a few lines of JavaScript that result in that error, and see if you’ll get your error message. Here is a simple change list that changes an error message. Toying around with the code like this will slowly get you familiar with the codebase and the build process.

To run your local modified V8 instead of the released version in the browser, use D8, V8’s debug shell. When you work with V8, you can use git just like you’re used to from other projects.

A change list in Chromium’s code review tool, Gerrit.

Once you get to the point where you can edit error messages and see the change in D8, upload your code and run all the tests on the V8 testing infrastructure. You should see some tests fail because we have tests that check the wording of error messages. This gets you familiar with our code review tool and how to run automated tests on our infrastructure, so you’re ready when you want to submit a patch. Details on how to use the V8 (Chromium) review tool and how to run the tests are here.

If you are familiar with JavaScript but not with C++, you might want to start by looking at V8/src/js. Parts of V8 are implemented in JavaScript, and they are in this folder. Most of this code directly implements JavaScript behavior as defined in the EcmaScript specification. Pick a function and look up its specification. Can you see how the specification corresponds to the code? If you change or delete part of the code, which tests are breaking, which steps in the specification are violated? There is also a lot of JavaScript code in V8/test, specifically V8/test/mjsunit.

As a next step, you can look through the V8 issue tracker. Maybe you find a small issue that you want to attempt to fix. Start by checking if you can understand and duplicate the issue. Write a small code snippet in JavaScript, that, when run, shows the issue. Poke around in the code. Intentionally break the code. Then run your test snippet to confirm that it fails because of the code you just broke. Play with the code. The V8 codebase is huge and complex. Maybe you can figure out enough to fix the issue. If not, no worries, you learnt something along the way when investigating the issue.

Making substantial changes in V8 is hard and requires a lot of time and knowledge. I would be lying if I told you that you can easily change how V8 works or add new features. But everybody has to start somewhere. Maybe you’ll stick with it and we see a change list from you in the future.

Have fun and enjoy learning! 🙂