| BindingAllocs.h |
Special allocation functions for DOM binding code.
|
1070 |
| CodeCoverage.h |
Enable the collection of lcov code coverage metrics.
Must be called before a runtime is created and before any calls to
GetCodeCoverageSummary.
|
1526 |
| CompileScript.h |
JavaScript API for compiling scripts to stencil without depending on
JSContext. |
5294 |
| CTypes.h |
Initialize the 'ctypes' object on a global variable 'obj'. The 'ctypes'
object will be sealed.
|
3003 |
| Intl.h |
Create and add the Intl.MozDateTimeFormat constructor function to the
provided object.
This custom date/time formatter constructor gives users the ability to
specify a custom format pattern. This pattern is passed *directly* to ICU
with NO SYNTAX PARSING OR VALIDATION WHATSOEVER. ICU appears to have a
modicum of testing of this, and it won't fall over completely if passed bad
input. But the current behavior is entirely under-specified and emphatically
not shippable on the web, and it *must* be fixed before this functionality
can be exposed in the real world. (There are also some questions about
whether the format exposed here is the *right* one to standardize, that will
also need to be resolved to ship this.)
If JS was built without JS_HAS_INTL_API, this function will throw an
exception.
|
1983 |
| JitInfo.h |
A class, expected to be passed by value, which represents the CallArgs for a
JSJitGetterOp.
|
11047 |
| JSStencil.h |
The `JS::Stencil` type holds the output of the JS Parser before it is
allocated on the GC heap as a `JSScript`. This form may be serialized as
part of building a bytecode cache. This `Stencil` is not associated with any
particular Realm and may be generated off-main-thread, making it useful for
building script loaders.
|
8674 |
| LoggingInterface.h |
_js_experimental_LoggingInterface_h_ |
3381 |
| PCCountProfiling.h |
Bytecode-level profiling support based on program counter offset within
functions and overall scripts.
SpiderMonkey compiles functions and scripts into bytecode representation.
During execution, SpiderMonkey can keep a counter of how often each bytecode
(specifically, bytecodes that are the targets of jumps) is reached, to track
basic information about how many times any particular bytecode in a script
or function is executed. These functions allow this counting to be started
and stopped, and the results of such counting to be examined.
Accumulated counting data is tracked per "script" (where "script" is either
a JavaScript function from source text or a top-level script or module).
Accumulated PCCount data thus prevents the particular scripts that were
executed from being GC'd. Once PCCount profiling has been stopped, you
should examine and then purge the accumulated data as soon as possible.
Much of the data tracked here is pretty internal and may only have meaning if
you're familiar with bytecode and Ion details. Hence why these APIs are
"experimental".
|
6202 |
| SourceHook.h |
The context-wide source hook allows the source of scripts/functions to be
discarded, if that source is constant and readily-reloadable if it's needed
in the future.
Ordinarily, functions and scripts store a copy of their underlying source, to
support |Function.prototype.toString| and debuggers. Some scripts, however,
might be constant and retrievable on demand -- perhaps burned into the binary
or in a readonly file provided by the embedding. Why not just ask the
embedding for a copy of the source?
The context-wide |SourceHook| gives embedders a way to respond to these
requests. The source of scripts/functions compiled with the compile option
|JS::CompileOptions::setSourceIsLazy(true)| is eligible to be discarded.
(The exact conditions under which source is discarded are unspecified.) *If*
source is discarded, performing an operation that requires source uses the
source hook to load the source.
The source hook must return the *exact* same source for every call. (This is
why the source hook is unsuitable for use with scripts loaded from the web:
in general, their contents can change over time.) If the source hook doesn't
return the exact same source, Very Bad Things may happen. (For example,
previously-valid indexes into the source will no longer be coherent: they
might index out of bounds, into the middle of multi-unit code points, &c.)
These APIs are experimental because they shouldn't provide a per-*context*
mechanism, rather something that's per-compilation.
|
4305 |
| TypedData.h |
Typed array, ArrayBuffer, and DataView creation, predicate, and accessor
functions.
|
28902 |