JS engine modularization

This page is still very much under construction and in the placeholder stage. Be gentle.

The goal of this project is to incrementally tease apart JS engine source code into separate "modules" so that:

• it is easier to understand a module in isolation
• it is easier to get a high-level breakdown of SM code
• module dependencies are DAG-y as opposed to clique-y or spaghetti (as it is now)

The plan isn't to do anything radical to simulate "modules" in C++. Rather, we can just say a "module" X is a triple: X.cpp, X.h, X-inl.h. Here, X.h acts as the "module interface" to the rest of the code-base. X-inl.h contains inline files that are pulled out of X.h so that:

• X.h is more readable as a whole and
• we can reduce average translation unit size (which right now is hard because of the dependency clique).

The granularity of modules isn't fixed; the goal is to try to have a module encapsulate a coherent hunk of interdependent logic and implementation details. This may be a single type (e.g., js::Value) or a set of related types (the stack types in vm/Stack.h).

Additionally, we can use directories to group related modules. Again, this is primarily useful to assist newcomers in developing a hierarchical understanding of the code.

Plan of Record

This is under construction!!

A meta bug tracks bugs for individual pieces: TODO

Preliminary directory/module structure:

• js/src
  • JSAPI implementation (jsapi.cpp, js::Invoke, js::Execute)
  • Interpreter (ideally, if we had maximum code reuse, this would be just the one function calling lots of module (inline) functions)
  • Grotty bits and bobs that don't make sense to modularize
• js/src/methodjit
• js/src/tracejit
• js/src/*jit
• js/src/vm: central, execution mode independent data structures: types and operations
  • Stack: execution stack (done)
  • Value: JS value representation
  • String: JS string value representation
  • Perhaps these next two need short distinctive names:
    • Low-level object representation: property tree, shapes, and raw object storage
    • General high-level objects: high level generic set/get/call operations respecting JS semantics
  • Class-specific high-level objects: statically typed interfaces for native objects of a given class
    • Global: the global object
    • Arguments: object accessed through 'arguments' keyword
    • Function: (object) perhaps also contains closely-related JSFunctino/JSScript/Bindings?
• js/src/gc: garbage collector data structures and algorithms
  • ...
• js/src/parser:
  • its not entirely clear how to cleanly break this into pieces, other than treating the whole thing as a module that takes in chars and puts out JSScripts
• js/src/builtin: builtins specified by JS language spec (e.g., String, Array.prototype.sort)
  • String
  • Number
  • Boolean
  • Array
  • Date
  • Math
  • ...