Hi,
tl;dr: Read section 2, and 2.1.
This email present the conclusion of 2 meetings about the self-hosted DOM
project. These 2 meetings were made to estimate the set of features and to
give time estimates for the completion of the project.
1/ Intentions
They are multiple intentions joining on this projects, among them we have:
* Cleaning up the JavaScript engine to avoid it being tied to the DOM of
Gecko.
* Taking advantage of JIT optimizations on the DOM functions:
- Using Escape Analysis to get rid of DOM structures.
- Using deforestation optimizations to avoid useless serializations for
CSS properties.
* Sharing DOM code between Servo and Gecko.
* Let JS modify DOM information which would be entirely represented in
native JS Objects.
* Read internal properties of C++ objects instead of mirroring values.
(window.document)
* Avoid function calls for simple functions (base64 to Ascii) to benefit
from memory safety of JS.
2/ Goal of the project
The goal of this project is to let embedders extend the scripts which are
part of the self-hosted compartment, such that the JavaScript code can have
intimate knowledge of the data structures while being optimizable by the JIT
compiler. In the case of Gecko and Servo, this concerns DOM functions,
which explains the name of this project "Self-hosted DOM".
Currently we settled on 2 group of goals, the minimal set with which we can
start experimenting with, and the rest, which might be needed in the long term.
2.1/ Minimal set of features for experimenting.
As part of the minimal set of features:
* We should give the ability for embedders to extend the set of intrinsics
functions of the self-hosted code, which means that embedders can have a
JSClass which refer to a function which is part of the self-hosted
compartment, and not only to a C++ native function.
* We should ensure that reserve slots are considered as any normal slot by
IonMonkey alias set analysis.
* We should extend JSFunctionSpec to add AliasSet information, such that
any native function can be annotated with the kind of objects that it might
mutate.
* We should hoist native function calls based on their AliasSet.
* Explicitly mention that we want to call a function which either a
self-hosted function or a non-self-hosted function (call content).
* Add JSClass intrinsics, such that the Self hosted code can reasons on
the DOM objects and hierarchies of DOM classes.
The total amount of work for reaching to the minimal set of features is
doable in one Quarter.
2.2/ Ideal set of features for production.
As part of the production-like features that we want, we raised a lot of
concerns about the safety of manipulating self-hosted code. One of the
biggest concern is that JavaScript is not as safe as C++ or Rust, and that
we might duplicate references which might go out of sync. Other concerns
are related to the impact on the start-up time of creating the self-hosted
compartment, as this is done every time we start the browser, and this might
matter a lot for Firefox for Android.
Safety concerns & potential solutions:
* Type-guards as intrinsics. (maybe use typescript as a front-end for
generating self-hosted code)
* Forbid method calls from self-hosted code.
* Add a way to insert equivalent use of AssertNoGC in Jit code.
* How do we ensure the safety of C++ offsets?
Start-up concerns & potential solutions:
* Use XDR to encode/decode the self-hosted code.
- Reduce the amount of duplicated atoms in XDR.
* Save Baseline generated code.
Additional concerns & features:
* Intrinsics for locking within JavaScript. (without shared array buffer)
* Having Type information for any slots (reserved) and not only properties.
* The executable size might increase a lot compared to the JSJitInfo alone
(which were already a concern).
* Access objects which are behind a wrapper.
The total amount of work to get the ideal set of feature was not estimated
during the meetings, and we should look at it later if the minimal set of
features proved to be useful enough to pursue this project.
3/ Additional notes:
The persons involved in these meetings were:
- Eric Faust (efaust)
- Nathan Froyd (froydnj)
- Nicolas B. Pierron (nbp)
- Till Schneidereit (till)
- Michael Wu (mwu)
- Boris Zbarsky (bz)
They are already a few bugs filed to address the minimal set of features
that we want to see to get the self-hosted DOM working.
Meeting notes: https://public.etherpad-mozilla.org/p/self-hosted-dom-m1
--
Nicolas B. Pierron
_______________________________________________
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
