- The profiler gives the JS engine a reference to the pseudo-stack via
SetContextProfiilngStack(). That function now takes a |PseudoStack*| instead
of a |ProfileEntry*| and pointer to the stack pointer.
- PseudoStack now has a |kMaxEntries| field, which is easier to work with than
|mozilla::ArrayLength(entries)|.
- AddressOfStackPointer() is no longer needed.
- The patch also neatens up the push operations significantly. PseudoStack now
has pushCppFrame() and pushJsFrame(), which nicely encapsulate the two main
cases. These delegate to the updated initCppFrame() and initJsFrame()
functions in ProfileEntry.
- Renames max_stck in testProfileStrings.cpp as peakStackPointer, which is a
clearer name.
- Removes a couple of checks from testProfileStrings.cpp. These checks made
sense when the pseudo-stack was accessed via raw manipulation, but are not
applicable now because we can't artificially limit the maximum stack size so
easily.
CompileOptions's column field has been conflating two meanings: the starting
column of the ScriptSource, and the starting column of the current thing
being compiled.
In the shell's evaluate() function, when the "column" option is passed,
it's fine to conflate the two meanings above.
When delazifying functions, it is incorrect to conflate the two
meanings. This is observable when generating SRC_CLASS_SPAN, which is a
srcnote used to save the toString offsets for a default class
constructor. (Since default class constructors aren't syntactically
present, there's no JSFunction made ahead of time. And since class
constructors must be toString'd as the class source instead of the
function source, we save the offsets in a srcnote to use when we
actually create the constructor at runtime.) When we save these offsets,
these are offsets into the ScriptSource buffer, and must be de-offset.
But it's incorrect to subtract the starting column of the lazy function,
which is itself offset from the starting column of the underlying
ScriptSource.
The shell has a very basic implementation of Promise job queue handling. This patch moves it into the engine, exposed through friendapi functions. The motivation is that I want to write JSAPI tests for streams, which requires Promise handling. The test harness would need essentially a copy of the shell's Promise handling, which isn't nice.
To be clear, the default implementation isn't used automatically: the embedding has to explicitly request it using js::UseInternalJobQueues.
MozReview-Commit-ID: 6bZ5VG5mJKV
The shell has a very basic implementation of Promise job queue handling. This patch moves it into the engine, exposed through friendapi functions. The motivation is that I want to write JSAPI tests for streams, which requires Promise handling. The test harness would need essentially a copy of the shell's Promise handling, which isn't nice.
To be clear, the default implementation isn't used automatically: the embedding has to explicitly request it using js::UseInternalJobQueues.
MozReview-Commit-ID: DwtPsJ0uMtP
Change FormatStackDump to return UniqueChars and fix up the users. This
removes a bit more manual memory management.
MozReview-Commit-ID: 60GBgeS4rzg
--HG--
extra : rebase_source : 15060321f567816ca434cdf1ef816d8322ceefff
This changes JS_smprintf to return UniqueChars, rather than relying on
manual memory management.
MozReview-Commit-ID: ENjQJODYdD1
--HG--
extra : rebase_source : 4c8ad4719dce205a7ef25e41eca25c5af793bb47
Remove the definition of sig_safe_t, which is only used by PseudoStack,
and replace the uses with mozilla::Atomic<uint32_t>.
MozReview-Commit-ID: GcPd9R94Vci
--HG--
extra : rebase_source : dcc05a219d59ffdc0486ef2e7118d888c6a93fda
clang's -Wcomma warning warns about suspicious use of the comma operator such as between two statements or to call a function for side effects within an expression.
js/src/builtin/MapObject.cpp:786:48 [-Wcomma] possible misuse of comma operator here
js/src/builtin/MapObject.cpp:1371:48 [-Wcomma] possible misuse of comma operator here
js/src/builtin/RegExp.cpp:1266:62 [-Wcomma] possible misuse of comma operator here
js/src/jit/x64/BaseAssembler-x64.h:624:99 [-Wcomma] possible misuse of comma operator here
js/src/jsarray.cpp:2416:27 [-Wcomma] possible misuse of comma operator here
js/src/jscompartment.cpp:120:48 [-Wcomma] possible misuse of comma operator here
js/src/jsstr.cpp:3346:14 [-Wcomma] possible misuse of comma operator here
js/xpconnect/src/XPCWrappedNativeJSOps.cpp:316:71 [-Wcomma] possible misuse of comma operator here
MozReview-Commit-ID: BbT4otUXczV
--HG--
extra : rebase_source : b232d10b5280c567f8fe390fcb56012b78da580a
This is accomplished in the following ways.
LazyScripts and JSScripts now have 4 offsets:
- Source begin and end for the actual source. This is used for lazy
parsing.
- toString begin and end for toString. Some kinds of functions, like
async, only have a different begin offset. Class constructors have
different offsets for both begin and end.
For syntactically present (i.e. non-default) constructors, the class
source span is remembered directly on the LazyScript or JSScript. The
toString implementation then splices out the substring directly.
For default constructors, a new SRC_CLASS SrcNote type is added. It's
binary and has as its arguments the begin and end offsets of the class
expression or statement. MakeDefaultConstructor reads the note and
overrides the cloned self-hosted function's source object. This is
probably the least intrusive way to accomplish this.
This is necessary to allow helper threads to attempt large allocations and recover from fragmentation situations with the LargeAllocationFailureCallback.
MozReview-Commit-ID: AyA3pbXcaYy
--HG--
extra : rebase_source : 7a5feb779b690ec7f123481e76f2390c850dac91
