In practice the previous test that was deleting Base Profiler data when the
index became greater that 1 was correct for Firefox, because the Base Profiler
*always* starts before the very first Gecko Profiler active instance.
However in tests (like the one in the following patch) this may not be true,
because each test may start and stop the profiler, and the recent storage update
means that the index doesn't go back to 1. So when a test (apart from the first
test to use the profiler) attemps to use the Base Profiler, that Base Profiler
data will be immediately discarded because the index is already greater than 1
(from previous tests).
This change is more future-proof as well, in case we later want to use the Base
Profiler more than once in a Firefox instance.
Differential Revision: https://phabricator.services.mozilla.com/D54445
--HG--
extra : moz-landing-system : lando
This ensures that no more Base Profiler (BP) activity can happen when Gecko
Profiler (GP) starts.
In particular on Linux this is needed because the BP sampler sends signals to
stop threads, and the just-starting GP could receive this signal before it is
fully ready to handle it with its own sampler.
Differential Revision: https://phabricator.services.mozilla.com/D54443
--HG--
extra : moz-landing-system : lando
JSON profiles from the Base Profiler were assumed to be empty if they contained
zero characters, but in fact they contain one character (a single newline).
Differential Revision: https://phabricator.services.mozilla.com/D54442
--HG--
extra : moz-landing-system : lando
In practice the previous test that was deleting Base Profiler data when the
index became greater that 1 was correct for Firefox, because the Base Profiler
*always* starts before the very first Gecko Profiler active instance.
However in tests (like the one in the following patch) this may not be true,
because each test may start and stop the profiler, and the recent storage update
means that the index doesn't go back to 1. So when a test (apart from the first
test to use the profiler) attemps to use the Base Profiler, that Base Profiler
data will be immediately discarded because the index is already greater than 1
(from previous tests).
This change is more future-proof as well, in case we later want to use the Base
Profiler more than once in a Firefox instance.
Differential Revision: https://phabricator.services.mozilla.com/D54445
--HG--
extra : moz-landing-system : lando
This ensures that no more Base Profiler (BP) activity can happen when Gecko
Profiler (GP) starts.
In particular on Linux this is needed because the BP sampler sends signals to
stop threads, and the just-starting GP could receive this signal before it is
fully ready to handle it with its own sampler.
Differential Revision: https://phabricator.services.mozilla.com/D54443
--HG--
extra : moz-landing-system : lando
JSON profiles from the Base Profiler were assumed to be empty if they contained
zero characters, but in fact they contain one character (a single newline).
Differential Revision: https://phabricator.services.mozilla.com/D54442
--HG--
extra : moz-landing-system : lando
If we are dealing with a markdown file with a front matter,
we read the information from the front matter/YAML,
write a new md file with the right information
and copy it in the target directory
Depends on D54426
Differential Revision: https://phabricator.services.mozilla.com/D54427
--HG--
extra : moz-landing-system : lando
For now, there is no flag to actually allow it, but this is the
code-side changes to allow the linker being disabled.
Differential Revision: https://phabricator.services.mozilla.com/D54074
--HG--
extra : moz-landing-system : lando
The custom linker used on Android (FaultyLib), can be enabled on
non-Android, and in the near future, may not always be enabled on
Android, so the FaultyLib-specific parts of the profile need to not be
specific to Android, but to the linker being enabled instead.
Differential Revision: https://phabricator.services.mozilla.com/D54073
--HG--
extra : moz-landing-system : lando
This function works on all GeckoProcessTypes, not just those for child
processes.
Differential Revision: https://phabricator.services.mozilla.com/D54375
--HG--
extra : moz-landing-system : lando
This function works on all GeckoProcessTypes, not just those for child
processes.
Differential Revision: https://phabricator.services.mozilla.com/D54375
--HG--
extra : moz-landing-system : lando
The docs used to recommend running 'watchman version' from the profile file.
But this doesn't actually seem to work for me. I don't remember why I even put
that in there. I finally took the time to get watchman set up as a systemd
service. This is just sharing the knowledge.
Differential Revision: https://phabricator.services.mozilla.com/D52404
--HG--
extra : moz-landing-system : lando
The name 'templates' originally came from the fact that JSON-e templates were
used to apply the configuration. Now that these no longer exist, the name
doesn't make any sense.
I'm not sure 'task_configs' is much better, but it at least makes sense given
that these are values that populate 'try_task_config.json'.
Differential Revision: https://phabricator.services.mozilla.com/D51418
--HG--
rename : tools/tryselect/templates.py => tools/tryselect/task_config.py
rename : tools/tryselect/test/test_templates.py => tools/tryselect/test/test_task_configs.py
extra : moz-landing-system : lando
Handles 'env' and 'chemspill-prio' configs in the transforms. The 'rebuild'
task config is purposefully excluded from the full_task_graph and instead
handled at the target_tasks stage. Otherwise if a user ran '--rebuild 20' then
retriggered one of those tasks, they'd instead get another 20 which is almost
certainly not what we want.
Differential Revision: https://phabricator.services.mozilla.com/D51417
--HG--
extra : moz-landing-system : lando
Also converts the 'artifact' from a Template to a TryConfig. So this changes the config from:
{
'templates': {
'artifact': {
'enabled': 1
}
}
}
to:
{
'use-artifact-builds': True
}
Differential Revision: https://phabricator.services.mozilla.com/D51416
--HG--
extra : moz-landing-system : lando
It is currently doing some C++ parsing.
And as we are extracting some snippets of code, it is
expected that they don't compile
Differential Revision: https://phabricator.services.mozilla.com/D54462
--HG--
extra : moz-landing-system : lando
This page isn't referened for now as Mike has been working in bringing
the MDN doc in-tree.
Differential Revision: https://phabricator.services.mozilla.com/D53979
--HG--
extra : moz-landing-system : lando
The native allocations feature added stackwalking that can happen anywhere that
memory is allocated. This means that stackwalking happens in places where the
execution already has a very large execution stack. Stackwalking was relying
on stack-allocated buffers used for merging stacks. This was taking up 64kb of
stack space. On Linux, this was causing a stack overflow, as there is only 256kb of
stack space. I encountered a crash while using GDB. Using pointer arithmetic,
I determined that the stack size before stack walking was around 20kb, and during
stackwalking, we overflowed the stack (>256kb). The largest culprit was the
JS::ProfilingFrameIterator::Frame jsFrames[MAX_JS_FRAMES]. In addition,
Bug 1468789 added another member to the Frame class, also increasing the size
of the stack allocation.
I changed the implementation to allocate some memory on the CorePS class, and
share that with every stackwalk that happens. I tested this loading a large news
site, and didn't get any crashes.
Differential Revision: https://phabricator.services.mozilla.com/D54072
--HG--
extra : moz-landing-system : lando
championshuttler
Sylvestre Ledru
Andi-Bogdan Postelnicu
Steve Fink
Olli Pettay
Nazım Can Altınova
Mihai Alexandru Michis
Julian Descottes
Gerald Squelart
Narcis Beleuzu
Mike Hommey
Andrew McCreight
Coroiu Cristina
Andrew Halberstadt
Greg Tatum