Open Bug 1515056 Opened 2 years ago Updated 9 months ago
[meta] Tighten up and improve jsm semantics to enable better performance
There are various idiosyncracies in the current implementation/semantics of jsms that hamper performance, make the JS engine folks unhappy, and make jsms "special" in a way that isn't conducive to migrating to more "standard" technologies like es6 modules. We'd like to take a number of different steps to enable better JIT/engine support and easier-to-reason-about code. The hope is that this will unlock perf improvements, improve maintainability, and make it easier to eventually migrate to ES6 modules. Non-exhaustive list of things we want to do in this space: 1. XDR/bytecode support. 2. Make jsm imports only produce the exported symbols. We currently have code that depends on being able to access other (non-exported) symbols from inside the jsm scope. bug 1514594 tracks fixing this. 3. lazy getters in the global jsm scope. JSMs currently use various XPCOMUtils and ChromeUtils methods to define various lazy getters on a `this` object, which we can't continue to rely on. We'd have to: - migrate ChromeUtils.defineModuleGetter() to a syntax somewhat like: let Services = ChromeUtils.lazyImport(".../Services.jsm"); - migrate XPCOMUtils.defineLazy...() to do either a similar thing or use other objects/symbols in the JSM to hang the extra properties off of. 4. For es6 import, there are some subtle differences in how changes to things inside the module (which were exported) are reflected to places that import the module. These types of changes should be rare/non-existent in our codebase, so we don't expect any issues with them. Ted, can you check this is a reasonable summary and correct where necessary? Thanks!
You need to log in before you can comment on or make changes to this bug.