Bugzilla

SpiderMonkey's `Debugger` API, first added in 2011, has cheerfully supported the
Firefox devtools across several generations of JavaScript JITs, but its
implementation is showing its age. Its interactions with the garbage collector
and just-in-time compilers are obscure. Despite having extensive unit tests,
`Debugger` is frequently implicated in fuzzer-blocking bugs. Its support for Web
Assembly evolves slowly, if at all. SpiderMonkey engineers cringe when tracking
down a bug leads them into the `Debugger`'s territory. Even `Debugger`'s
original designers encounter a steady stream of unexpected obstacles when adding
support for new ECMAScript features like generators and asynchronous functions.

In any software project, for engineers to be able to accurately estimate the
time required to implement a change, certain preconditions must hold:

1)   The features that `Debugger` provides must have clear, accurate documentation.

2)   The demands that `Debugger` places on the rest of SpiderMonkey in order to
     implement those features must be documented similarly.

3)   Within the implementation, each component's requirements and promises must be
     evident to any reasonably skilled developer.

4)   The code must be thoroughly tested.

At the moment, only condition 4) is well in hand. As a result, estimates for
`Debugger` work have a lot of uncertainty, and it is difficult for new engineers
to contribute to the code. To have accurate estimates and a comfortable “bus
factor”, we need to invest in refactoring and simplifying the `Debugger`
implementation.

SpiderMonkey's `Debugger` API, first added in 2011, has cheerfully supported the Firefox devtools across several generations of JavaScript JITs, but its implementation is showing its age. Its interactions with the garbage collector and just-in-time compilers are obscure. Despite having extensive unit tests, `Debugger` is frequently implicated in fuzzer-blocking bugs. Its support for Web Assembly evolves slowly, if at all. SpiderMonkey engineers cringe when tracking down a bug leads them into the `Debugger`'s territory. Even `Debugger`'s original designers encounter a steady stream of unexpected obstacles when adding support for new ECMAScript features like generators and asynchronous functions.

In any software project, for engineers to be able to accurately estimate the time required to implement a change, certain preconditions must hold:

1)   The features that `Debugger` provides must have clear, accurate documentation.

2)   The demands that `Debugger` places on the rest of SpiderMonkey in order to implement those features must be documented similarly.

3)   Within the implementation, each component's requirements and promises must be evident to any reasonably skilled developer.

4)   The code must be thoroughly tested.

At the moment, only condition 4) is well in hand. As a result, estimates for `Debugger` work have a lot of uncertainty, and it is difficult for new engineers to contribute to the code. To have accurate estimates and a comfortable “bus factor”, we need to invest in refactoring and simplifying the `Debugger` implementation.