Bug 1688794 Comment 20 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

The self-hosted zone provides data for a number of uses that must each by
replaced with new machanisms:
 - Permanent Atoms: All atoms generated by parsing selfhosted.js are added to
   the permanent atom set that is frozen and shared with worker runtimes
   directly. We now use the self-hosted stencil to know what atoms are used and
   continue to create them at startup.
 - C++ Instrinsics: Self-hosted code calls back into the VM using a few hundred
   intrinsic functions. Previously these were initialized on the self-hosted
   GlobalObject and cloned on demand. Now, we directly search the JSFunctionSpec
   static data for a match and create the JSFunction on demand. This is then
   cached on the realm intrinsics holder for subsequent calls.
 - JS_SELF_HOSTED_FN: Methods of builtin interfaces may be implemented with
   self-hosted code. These start as special self-hosted lazy JSFunctions that
   are delazified as needed. We look up canonical name / nargs from the stencil
   now instead of the s-h zone.
 - JSOp::GetIntrinsic for functions: When self-hosted code calls other
   self-hosted functions, GetIntrinsic opcodes are used. Previously this would
   trigger a deep-clone, but now we simply create a lazy self-hosted JSFunction.
 - Non-delazifying attribute lookups: The getSelfHostedFunctionGeneratorKind
   function would directly lookup attributes on the self-hosted zone without
   first triggering delazification. Now we do a similar lookup directly on the
   stencil data.
 - JSOp::GetIntrinsic for non-function values: The top-level script defines a
   small number of variables with JSOp::SetIntrinsic that were previously cloned
   on demand to target realms. We now run the top-level script directly in the
   target realm. This is done on demand when a self-hosted value lookup is not
   served by any other source. An example is `listFormatInternalProperties`.
The self-hosted zone provides data for a number of uses that must each by
replaced with new machanisms:
 - Permanent Atoms: All atoms generated by parsing selfhosted.js are added to
   the permanent atom set that is frozen and shared with worker runtimes
   directly. We now use the self-hosted stencil to know what atoms are used and
   continue to create them at startup.
 - C++ Instrinsics: Self-hosted code calls back into the VM using a few hundred
   intrinsic functions. Previously these were initialized on the self-hosted
   GlobalObject and cloned on demand. Now, we directly search the JSFunctionSpec
   static data for a match and create the JSFunction on demand. This is then
   cached on the realm intrinsics holder for subsequent calls.
 - JS_SELF_HOSTED_FN: Methods of builtin interfaces may be implemented with
   self-hosted code. These start as special self-hosted lazy JSFunctions that
   are delazified as needed. We look up canonical name / nargs from the stencil
   now instead of the s-h zone.
 - JSOp::GetIntrinsic for functions: When self-hosted code calls other
   self-hosted functions, GetIntrinsic opcodes are used. Previously this would
   trigger a deep-clone, but now we simply create a lazy self-hosted JSFunction.
 - Delazification: Previously we would clone BaseScript data from the s-h zone
   when we needed to delazify. Now we directly instantiate from the stencil.
   This uses a special form of stencil instantiation that can work on a partial
   sub-tree of the stencil (corresponding to a single top-level function and any
   of its inner functions).
 - Non-delazifying attribute lookups: The getSelfHostedFunctionGeneratorKind
   function would directly lookup attributes on the self-hosted zone without
   first triggering delazification. Now we do a similar lookup directly on the
   stencil data.
 - JSOp::GetIntrinsic for non-function values: The top-level script defines a
   small number of variables with JSOp::SetIntrinsic that were previously cloned
   on demand to target realms. We now run the top-level script directly in the
   target realm. This is done on demand when a self-hosted value lookup is not
   served by any other source. An example is `listFormatInternalProperties`.

Back to Bug 1688794 Comment 20