Sicne some tests doesn't work with --with-intl-api=no, we should skip it on Android
MozReview-Commit-ID: IjlH3aQdiqb
--HG--
extra : rebase_source : ac6d91bf291f6268ea29bcb29180b2f5197e012c
Now that we join on the thread exiting, we no longer need to have the thread
explicitly tell us it's shutting down.
MozReview-Commit-ID: LycPjUvyeX
--HG--
extra : rebase_source : 7b3d21c3d8de73a1ed511c7d6efefe2a73b2e02a
Currently, JS sampling has major problems.
- JS sampling is enabled for all JS threads from the thread that runs
locked_profiler_start() -- currently only the main thread -- but the JS
engine can't handle enabling from off-thread, and asserts. This makes
profiling workers impossible in a debug build.
- No JS thread will be JS sampled unless enableJSSampling() is called, but that
only happens in locked_profiler_start(). That means any worker threads
created while the profiler is active won't be JS sampled.
- Only the thread that runs locked_profiler_stop() -- currently only the main
thread -- ever calls disableJSSampling(). This means that worker threads that
start being JS sampled never stop being JS sampled.
This patch fixes these three problems in the following ways.
- locked_profiler_start() now sets a flag in PseudoStack that indicates
JS sampling is desired, but doesn't directly enable it. Instead, the JS
thread polls that flag and enables JS sampling itself when it sees the flag
is set. The polling is done by the interrupt callback. There was already a
flag of this sort (mJSSampling) but the new one is better.
This required adding a call to profiler_js_operation_callback() to the
InterruptCallback() in XPCJSContext.cpp. (In comparison, the
InterruptCallback() in dom/workers/RuntimeService.cpp already had such a
call.)
- RegisterCurrentThread() now requests JS sampling of a JS thread when the
profiler is active, the thread is being profiled, and JS sampling is enabled.
- locked_profiler_stop() now calls stopJSSampling() on all live threads.
The patch makes the following smaller changes as well.
- Renames profiler_js_operation_callback() as profiler_js_interrupt_callback(),
because "interrupt callback" is the standard name (viz.
JS_AddInterruptCallback()).
- Calls js::RegisterContextProfilingEventMarker() with nullptr when stopping
JS sampling, so that ProfilerJSEventMarker won't fire unnecessarily.
- Some minor formatting changes.
--HG--
extra : rebase_source : 372f94c963a9e5b2493389892499b1ca205ebc2f
PseudoContext::sampleContext() is always called immediately after
profiler_get_pseudo_stack(). This patch introduces profiler_set_js_context()
and profiler_clear_js_context(), which replace the profiler_get_pseudo_stack()
+ sampleContext() pairs. This takes us a step closer to not having to export
PseudoStack outside the profiler.
--HG--
extra : rebase_source : 8558d1600eafd395cc696d31f3d21fb52a1a74b0
In many cases, to speed up start, compiling a ScriptSource will not
compile the functions themselves, but will rather syntax-parse them
(to check for syntax errors), leaving full compilation for
later. However, if we find ourselves in a case in which the function
is needed almost immediately, we need to full-parse the function
immediately after the syntax-parse, which is wasteful.
This changeset intends to measure how often this happens, by exporting
through Telemetry the duration between the end of the syntax-parse and
the start of the full-parse for each function.
As a memory optimization, instead of storing a timestamp for the
syntax-parse of each function, we store a single timestamp for an
entire ScriptSource. This assumes that all functions of the
ScriptSource are syntax-parsed at approximately the same instant,
which should be mostly true for everything except perhaps `eval` and
`new Function`. Then, when time comes to delazify a function, we
simply determine the time elapsed since the ScriptSource was compiled.
Histogram JS_PARSER_COMPILE_LAZY_AFTER_MS starts at 10ms (anything
smaller is often not measurable) and stops at 10s (anything larger can
safely be said to be not wasteful).
MozReview-Commit-ID: 6Ycy2OIIiAt
--HG--
extra : rebase_source : 0ccd6f51189b3ad8056e9f39e267235d68f6e2db
This patch is generated by the following sed script:
find . ! -wholename '*/.hg*' -type f \( -iname '*.html' -o -iname '*.xhtml' -o -iname '*.xul' -o -iname '*.js' \) -exec sed -i -e 's/\(\(text\|application\)\/javascript\);version=1.[0-9]/\1/g' {} \;
MozReview-Commit-ID: AzhtdwJwVNg
--HG--
extra : rebase_source : e8f90249454c0779d926f87777f457352961748d
The profiler can currently handle nested calls to profiler_{init,shutdown}() --
only the first call to profiler_init() and the last call to profiler_shutdown()
do anything. And sure enough, we have the following.
- Outer init/shutdown pairs in XRE_main()/XRE_InitChildProcess() (via
GeckoProfilerInitRAII).
- Inner init/shutdown pairs in NS_InitXPCOM2()/NS_InitMinimalXPCOM() (both shut
down in ShutdownXPCOM()).
This is a bit silly, so the patch removes the inner pairs, and adds a
now-needed pair in XRE_XPCShellMain. This will allow gInitCount -- which tracks
the nesting depth -- to be removed in a future patch.
--HG--
extra : rebase_source : 7e8dc6ce81ce10269d2db6a7bf32852c396dba0e