MozillaWiki - User contributions [en]

Sfink/Moving GC

2025-11-19T19:57:40Z

Sfink: clarify some small things

All garbage collectors (GC) need to know what objects are reachable and therefore need
to be alive. Tracing GCs require a way to find the exact set of objects that are
currently reachable. This requires knowing about all pointers into the JS heap
("roots"), as well as all pointers within the JS heap (the "heap graph"). GC
will do a graph traversal starting from the roots and visiting everything
reachable.

A generational garbage collector (GGC) defines a subset of the JS heap as the
"nursery", and allocates most objects out of this nursery in the expectation
that many of them will die quickly (become unused and unreachable). The
collector periodically sweeps through the nursery, packing only the live
objects into another area so that the nursery is empty and available for new
allocations again. It is important that this nursery sweep (a "minor
collection") only needs to look at the *live* objects (plus some bookkeeping
information), NOT the full heap or even a percentage of it -- you want the
cost of minor collections to be proportional to only the amount of live data in
the nursery, and independent of the amount of garbage.

This requires two main capabilities: (1) the ability to move objects around,
and (2) a record of all external pointers into the nursery.

Incremental garbage collection (IGC) adds an additional requirement: at the
beginning of an incremental collection, all roots (external pointers) into the
heap are recorded, then the main program is allowed to continue running but is
interrupted periodically so the incremental collector can gradually trace the
whole heap graph. Because the graph can change during the overall duration of this sweep, any
intra-heap reference that is deleted must be marked (treated as live): such
referents are usually either dead or reachable from somewhere else, but it's also possible that the main program
moved a reference from a part of the heap that has not yet been scanned to a
part that has already been scanned, and so the referent will not get marked during the
rest of the incremental collection. This adds a required capability (3): a
record of all pointers within the heap that were deleted while incremental GC
was active. (Note: this is actually accomplished by pushing them on the same mark stack used to record the current state of the incremental GC.)

Capability #1 means that we need to be able to find and update all pointers
from outside the JS heap into the JS heap. (Intra-heap pointers can be found
and updated by scanning, so they don't need any special handling.) The embedding uses APIs to register certain data structures as part of the root set, as well as callbacks to record other root pointers during the GC. For pointers on the stack, we use the Stack Rooting API; see js/public/RootingAPI.h.

Capabilities #2 and #3 mean that we need "write barriers" for all JS heap
pointers stored within the C++ heap, which is a fancy way of saying that if you
modify a pointer into the heap, you may need to do something before and/or after
the write to update bookkeeping information. Capability #2 requires a
"post-write barrier" aka post barrier, an action taken after the write occurs, to store a record of
any new pointer value that points (or might point) into the nursery. Capability #3
requires a "pre-write barrier" aka pre barrier, an action taken before the write occurs, so it can
mark the overwritten value as live (before it is lost from the
graph). The exact timing isn't critical; the pre barrier really just needs the old value
and the post barrier needs the new value, but both could run either before or after the actual
write (as long as there's no possibility of a GC in between the barrier and the write!)

---

You can divide memory into 4 partitions: the stack, the non-JS (C++) heap, the
JS nursery, and the JS tenured area. (Or you could say there's the stack and
the heap, and the heap is divided into JS and non-JS parts, and the JS part is
separated into a nursery and a tenured area, but it's the pointers between
these areas that matter so we'll keep them separate.)

Pointers from the stack to either part of the JS heap must be findable and
updatable during a moving GC. This is usually accomplished with Rooted<T>,
Handle<T>, and MutableHandle<T>, though aggregates of various sorts will also
use Auto*Rooter classes. Pointers from the stack to either the
stack or the C++ heap don't matter (such pointers are not pointing to GC things.)

Pointers from the C++ heap to the JS heap must be findable and updatable, and
writes must be barriered. Pointers from the C++ heap to the C++ heap don't matter to the GC. Pointers
from the C++ heap to the stack are kind of funky but don't matter to the GC.

Pointers from the tenured area to anywhere in the JS heap are automatically
findable and updatable, since you can scan the JS heap. Writes do need to be
barriered, in case they change to point to the nursery (for GGC) or move an
unscanned subgraph into the already-scanned region (for IGC). Pointers from
tenured to the stack (?!) or the C++ heap don't matter (again, these aren't pointing at GC things.)

Pointers from the nursery are the same as those from tenured, except it doesn't
matter for GGC if a nursery pointer points to the nursery vs tenured since everything still alive in the nursery will be scanned. So the
post barrier is not needed. The pre barrier is not needed because incremental GC does a nursery collection when it begins, and anything
allocated from that point to the end of the GC will always be treated as live.

Javascript:Hazard Builds

2021-04-28T18:24:25Z

Sfink: attempt4

{{OutdatedSpiderMonkey|replacement=https://firefox-source-docs.mozilla.org/js/HazardAnalysis/}}

== Static Analysis for Rooting and Heap Write Hazards ==

Treeherder can run two static analysis builds: the full browser (linux64-haz), just the JS shell (linux64-shell-haz). They show up on treeherder as '''H''' and '''SM(H)'''.

=== Diagnosing a hazard failure ===

The first step is to look at what sort of hazard is being reported. There are two types that cause the job to fail: stack rooting hazards for garbage collection, and heap write thread safety hazards for stylo.

The summary output will include either the string "<N> rooting hazards detected" or "<N> heap write hazards detected out of <M> allowed". See the appropriate section below for each.

=== Diagnosing a rooting hazards failure ===

Click on the '''H''' build link, select the "Job details" pane on the bottom right, follow the "Inspect Task" link, and download the "<code>public/build/hazards.txt.gz</code>" file.

Example snippet:

<pre>
Function 'jsopcode.cpp:uint8 DecompileExpressionFromStack(JSContext*, int32, int32, class JS::Handle<JS::Value>, int8**)' has unrooted 'ed' of type 'ExpressionDecompiler' live across GC call 'uint8 ExpressionDecompiler::decompilePC(uint8*)' at js/src/jsopcode.cpp:1866
js/src/jsopcode.cpp:1866: Assume(74,75, !__temp_23*, true)
js/src/jsopcode.cpp:1867: Assign(75,76, return := 0)
js/src/jsopcode.cpp:1867: Call(76,77, ed.~ExpressionDecompiler())
GC Function: uint8 ExpressionDecompiler::decompilePC(uint8*)
JSString* js::ValueToSource(JSContext*, class JS::Handle<JS::Value>)
uint8 js::Invoke(JSContext*, JS::Value*, JS::Value*, uint32, JS::Value*, class JS::MutableHandle<JS::Value>)
uint8 js::Invoke(JSContext*, JS::CallArgs, uint32)
JSScript* JSFunction::getOrCreateScript(JSContext*)
uint8 JSFunction::createScriptForLazilyInterpretedFunction(JSContext*, class JS::Handle<JSFunction*>)
uint8 JSRuntime::cloneSelfHostedFunctionScript(JSContext*, class JS::Handle<js::PropertyName*>, class JS::Handle<JSFunction*>)
JSScript* js::CloneScript(JSContext*, class JS::Handle<JSObject*>, class JS::Handle<JSFunction*>, const class JS::Handle<JSScript*>, uint32)
JSObject* js::CloneStaticBlockObject(JSContext*, class JS::Handle<JSObject*>, class JS::Handle<js::StaticBlockObject*>)
js::StaticBlockObject* js::StaticBlockObject::create(js::ExclusiveContext*)
js::Shape* js::EmptyShape::getInitialShape(js::ExclusiveContext*, js::Class*, js::TaggedProto, JSObject*, JSObject*, uint32, uint32)
js::Shape* js::EmptyShape::getInitialShape(js::ExclusiveContext*, js::Class*, js::TaggedProto, JSObject*, JSObject*, uint64, uint32)
js::UnownedBaseShape* js::BaseShape::getUnowned(js::ExclusiveContext*, js::StackBaseShape*)
js::BaseShape* js_NewGCBaseShape(js::ThreadSafeContext*) [with js::AllowGC allowGC = (js::AllowGC)1u]
js::BaseShape* js::gc::NewGCThing(js::ThreadSafeContext*, uint32, uint64, uint32) [with T = js::BaseShape; js::AllowGC allowGC = (js::AllowGC)1u; size_t = long unsigned int]
void js::gc::RunDebugGC(JSContext*)
void js::MinorGC(JSRuntime*, uint32)
GC
</pre>

This means that a rooting hazard was discovered at <code>js/src/jsopcode.cpp</code> line 1866, in the function <code>DecompileExpressionFromStack</code> (it is prefixed with the filename because it's a static function.) The problem is that they're an unrooted variable '<code>ed</code>' that holds an <code>ExpressionDecompiler</code> live across a call to <code>decompilePC</code>. "Live" means that the variable is used after the call to <code>decompilePC</code> returns. <code>decompilePC</code> may trigger a GC according to the static call stack given starting from the line beginning with "GC Function:". The hazard itself has some barely comprehensible Assume(...) and Call(...) gibberish that describes the exact path of the variable into the function call. That stuff is rarely useful -- usually, you'll only need to look at it if it's complaining about a temporary and you want to know where the temporary came from. The type '<code>ExpressionDecompiler</code>' is believed to hold pointers to GC-controlled objects of some sort. The analysis currently does not describe the exact field it is worried about.

To unpack this a little, the analysis is saying the following can happen:

* <code>ExpressionDecompiler</code> contains some pointer to a GC thing. For example, it might have a field '<code>obj</code>' of type '<code>JSObject*</code>'.
* <code>DecompileExpressionFromStack</code> is called.
* A pointer is stored in that field of the '<code>ed</code>' variable.
* <code>decompilePC</code> is invoked, which calls <code>ValueToSource</code>, which calls <code>Invoke</code>, which eventually calls <code>js::MinorGC</code>
* during the resulting garbage collection, the object pointed to by <code>ed.obj</code> is moved to a different location. All pointers stored in the JS heap are updated automatically, as are all rooted pointers. <code>ed.obj</code> is not, because the GC doesn't know about it.
* after <code>decompilePC</code> returns, something accesses <code>ed.obj</code>. This is now a stale pointer, and may refer to just about anything -- the wrong object, an invalid object, or whatever. Badness 10000, as TeX would say.

=== Diagnosing a heap write hazard failure ===

For the thread unsafe heap write analysis, a hazard means that some Gecko_* function calls, directly or indirectly, code that writes to something on the heap, or calls an unknown function that *might* write to something on the heap. The analysis requires quite a few annotations to describe things that are actually safe. This section will be expanded as we gain more experience with the analysis, but here are some common issues:

* Adding a new Gecko_* function: often, you will need to annotate any outparams or owned (thread-local) parameters in the <code>treatAsSafeArgument</code> function in <code>js/src/devtools/rootAnalysis/analyzeHeapWrites.js</code>.
* Calling some libc function: if you add a call to some random libc function (eg sin() or floor() or ceil(), though the latter two are already annotated), the analysis will report an "External Function". Add it to <code>checkExternalFunction</code>, assuming it *doesn't* have the possibility of writing to shared heap memory.
* If you call some non-returning (crashing) function that the analysis doesn't know about, you'll need to add it to <code>ignoreContents</code>.

On the other hand, you might have a real thread safety issue on your hands. Shared caches are common problems. Fix it.

=== Analysis implementation ===

These builds are performed as follows:

* run the script testing/taskcluster/scripts/builder/build-haz-linux.sh, which sets up a build environment and runs the analysis within it, then uploads the resulting files
** compile an optimized JS shell to later run the analysis
** compile the browser with gcc, using a slightly modified version of the sixgill (http://svn.sixgill.org) gcc plugin, producing a set of .xdb files describing everything encountered during the compilation
** analyze the .xdb files with scripts in js/src/devtools/rootAnalysis

=== Running the analysis ===

==== Pushing to try ====

The easiest way to run an analysis is to push to try with the trychooser line |try: -b do -p linux64-haz| (or, if the hazards of interest are contained entirely within js/src, use |try: -b do -p linux64-shell-haz| for a much faster result). The expected turnaround time for linux64-haz is just under 2 hours.

The output will be uploaded and a link named "results" will be placed into the "job details" info pane on treeherder. If the analysis fails, you will see the number of failures. Navigate to the hazards.txt.gz file.

==== Running locally ====

To run the browser analysis, you must be on a Fedora/RedHat/CentOS linux64 machine. See js/src/devtools/rootAnalysis/README.md.

If you are running Debian or Ubuntu, then there is currently a problem running the full browser analysis. You can coerce the shell-only build to work by doing something like:

sudo apt-get install autoconf2.13 libnspr4 libnspr4-dev
sudo ln -s autoconf2.13 /usr/bin/autoconf-2.13
export CFLAGS="-B/usr/lib/x86_64-linux-gnu -I/usr/include/x86_64-linux-gnu"
export CXXFLAGS="-B/usr/lib/x86_64-linux-gnu -I/usr/include/x86_64-linux-gnu"

before running the script.

=== So you broke the analysis by adding a hazard. Now what? ===

Backout, fix the hazard, or (final resort) update the expected number of hazards in js/src/devtools/rootAnalysis/expect.browser.json (but don't do that).

The most common way to fix a hazard is to change the variable to be a Rooted type, as described in http://dxr.mozilla.org/mozilla-central/source/js/public/RootingAPI.h#l21

For more complicated cases, ask on #jsapi. If you don't get a response, ping sfink or jonco for rooting hazards, bholley or sfink for heap write hazards. Or if it's a deeper issue with the analysis logic, try bhackett (the author of both analyses.)

Javascript:Hazard Builds

2021-04-28T18:23:51Z

Sfink: attempt3

{{OutdatedSpiderMonkey|replacement=[https://firefox-source-docs.mozilla.org/js/HazardAnalysis/|https://firefox-source-docs.mozilla.org/js/HazardAnalysis/]}}

== Static Analysis for Rooting and Heap Write Hazards ==

Treeherder can run two static analysis builds: the full browser (linux64-haz), just the JS shell (linux64-shell-haz). They show up on treeherder as '''H''' and '''SM(H)'''.

=== Diagnosing a hazard failure ===

The first step is to look at what sort of hazard is being reported. There are two types that cause the job to fail: stack rooting hazards for garbage collection, and heap write thread safety hazards for stylo.

The summary output will include either the string "<N> rooting hazards detected" or "<N> heap write hazards detected out of <M> allowed". See the appropriate section below for each.

=== Diagnosing a rooting hazards failure ===

Click on the '''H''' build link, select the "Job details" pane on the bottom right, follow the "Inspect Task" link, and download the "<code>public/build/hazards.txt.gz</code>" file.

Example snippet:

<pre>
Function 'jsopcode.cpp:uint8 DecompileExpressionFromStack(JSContext*, int32, int32, class JS::Handle<JS::Value>, int8**)' has unrooted 'ed' of type 'ExpressionDecompiler' live across GC call 'uint8 ExpressionDecompiler::decompilePC(uint8*)' at js/src/jsopcode.cpp:1866
js/src/jsopcode.cpp:1866: Assume(74,75, !__temp_23*, true)
js/src/jsopcode.cpp:1867: Assign(75,76, return := 0)
js/src/jsopcode.cpp:1867: Call(76,77, ed.~ExpressionDecompiler())
GC Function: uint8 ExpressionDecompiler::decompilePC(uint8*)
JSString* js::ValueToSource(JSContext*, class JS::Handle<JS::Value>)
uint8 js::Invoke(JSContext*, JS::Value*, JS::Value*, uint32, JS::Value*, class JS::MutableHandle<JS::Value>)
uint8 js::Invoke(JSContext*, JS::CallArgs, uint32)
JSScript* JSFunction::getOrCreateScript(JSContext*)
uint8 JSFunction::createScriptForLazilyInterpretedFunction(JSContext*, class JS::Handle<JSFunction*>)
uint8 JSRuntime::cloneSelfHostedFunctionScript(JSContext*, class JS::Handle<js::PropertyName*>, class JS::Handle<JSFunction*>)
JSScript* js::CloneScript(JSContext*, class JS::Handle<JSObject*>, class JS::Handle<JSFunction*>, const class JS::Handle<JSScript*>, uint32)
JSObject* js::CloneStaticBlockObject(JSContext*, class JS::Handle<JSObject*>, class JS::Handle<js::StaticBlockObject*>)
js::StaticBlockObject* js::StaticBlockObject::create(js::ExclusiveContext*)
js::Shape* js::EmptyShape::getInitialShape(js::ExclusiveContext*, js::Class*, js::TaggedProto, JSObject*, JSObject*, uint32, uint32)
js::Shape* js::EmptyShape::getInitialShape(js::ExclusiveContext*, js::Class*, js::TaggedProto, JSObject*, JSObject*, uint64, uint32)
js::UnownedBaseShape* js::BaseShape::getUnowned(js::ExclusiveContext*, js::StackBaseShape*)
js::BaseShape* js_NewGCBaseShape(js::ThreadSafeContext*) [with js::AllowGC allowGC = (js::AllowGC)1u]
js::BaseShape* js::gc::NewGCThing(js::ThreadSafeContext*, uint32, uint64, uint32) [with T = js::BaseShape; js::AllowGC allowGC = (js::AllowGC)1u; size_t = long unsigned int]
void js::gc::RunDebugGC(JSContext*)
void js::MinorGC(JSRuntime*, uint32)
GC
</pre>

This means that a rooting hazard was discovered at <code>js/src/jsopcode.cpp</code> line 1866, in the function <code>DecompileExpressionFromStack</code> (it is prefixed with the filename because it's a static function.) The problem is that they're an unrooted variable '<code>ed</code>' that holds an <code>ExpressionDecompiler</code> live across a call to <code>decompilePC</code>. "Live" means that the variable is used after the call to <code>decompilePC</code> returns. <code>decompilePC</code> may trigger a GC according to the static call stack given starting from the line beginning with "GC Function:". The hazard itself has some barely comprehensible Assume(...) and Call(...) gibberish that describes the exact path of the variable into the function call. That stuff is rarely useful -- usually, you'll only need to look at it if it's complaining about a temporary and you want to know where the temporary came from. The type '<code>ExpressionDecompiler</code>' is believed to hold pointers to GC-controlled objects of some sort. The analysis currently does not describe the exact field it is worried about.

To unpack this a little, the analysis is saying the following can happen:

* <code>ExpressionDecompiler</code> contains some pointer to a GC thing. For example, it might have a field '<code>obj</code>' of type '<code>JSObject*</code>'.
* <code>DecompileExpressionFromStack</code> is called.
* A pointer is stored in that field of the '<code>ed</code>' variable.
* <code>decompilePC</code> is invoked, which calls <code>ValueToSource</code>, which calls <code>Invoke</code>, which eventually calls <code>js::MinorGC</code>
* during the resulting garbage collection, the object pointed to by <code>ed.obj</code> is moved to a different location. All pointers stored in the JS heap are updated automatically, as are all rooted pointers. <code>ed.obj</code> is not, because the GC doesn't know about it.
* after <code>decompilePC</code> returns, something accesses <code>ed.obj</code>. This is now a stale pointer, and may refer to just about anything -- the wrong object, an invalid object, or whatever. Badness 10000, as TeX would say.

=== Diagnosing a heap write hazard failure ===

For the thread unsafe heap write analysis, a hazard means that some Gecko_* function calls, directly or indirectly, code that writes to something on the heap, or calls an unknown function that *might* write to something on the heap. The analysis requires quite a few annotations to describe things that are actually safe. This section will be expanded as we gain more experience with the analysis, but here are some common issues:

* Adding a new Gecko_* function: often, you will need to annotate any outparams or owned (thread-local) parameters in the <code>treatAsSafeArgument</code> function in <code>js/src/devtools/rootAnalysis/analyzeHeapWrites.js</code>.
* Calling some libc function: if you add a call to some random libc function (eg sin() or floor() or ceil(), though the latter two are already annotated), the analysis will report an "External Function". Add it to <code>checkExternalFunction</code>, assuming it *doesn't* have the possibility of writing to shared heap memory.
* If you call some non-returning (crashing) function that the analysis doesn't know about, you'll need to add it to <code>ignoreContents</code>.

On the other hand, you might have a real thread safety issue on your hands. Shared caches are common problems. Fix it.

=== Analysis implementation ===

These builds are performed as follows:

* run the script testing/taskcluster/scripts/builder/build-haz-linux.sh, which sets up a build environment and runs the analysis within it, then uploads the resulting files
** compile an optimized JS shell to later run the analysis
** compile the browser with gcc, using a slightly modified version of the sixgill (http://svn.sixgill.org) gcc plugin, producing a set of .xdb files describing everything encountered during the compilation
** analyze the .xdb files with scripts in js/src/devtools/rootAnalysis

=== Running the analysis ===

==== Pushing to try ====

The easiest way to run an analysis is to push to try with the trychooser line |try: -b do -p linux64-haz| (or, if the hazards of interest are contained entirely within js/src, use |try: -b do -p linux64-shell-haz| for a much faster result). The expected turnaround time for linux64-haz is just under 2 hours.

The output will be uploaded and a link named "results" will be placed into the "job details" info pane on treeherder. If the analysis fails, you will see the number of failures. Navigate to the hazards.txt.gz file.

==== Running locally ====

To run the browser analysis, you must be on a Fedora/RedHat/CentOS linux64 machine. See js/src/devtools/rootAnalysis/README.md.

If you are running Debian or Ubuntu, then there is currently a problem running the full browser analysis. You can coerce the shell-only build to work by doing something like:

sudo apt-get install autoconf2.13 libnspr4 libnspr4-dev
sudo ln -s autoconf2.13 /usr/bin/autoconf-2.13
export CFLAGS="-B/usr/lib/x86_64-linux-gnu -I/usr/include/x86_64-linux-gnu"
export CXXFLAGS="-B/usr/lib/x86_64-linux-gnu -I/usr/include/x86_64-linux-gnu"

before running the script.

=== So you broke the analysis by adding a hazard. Now what? ===

Backout, fix the hazard, or (final resort) update the expected number of hazards in js/src/devtools/rootAnalysis/expect.browser.json (but don't do that).

The most common way to fix a hazard is to change the variable to be a Rooted type, as described in http://dxr.mozilla.org/mozilla-central/source/js/public/RootingAPI.h#l21

For more complicated cases, ask on #jsapi. If you don't get a response, ping sfink or jonco for rooting hazards, bholley or sfink for heap write hazards. Or if it's a deeper issue with the analysis logic, try bhackett (the author of both analyses.)

Javascript:Hazard Builds

2021-04-28T18:23:09Z

Sfink: attempt2

{{OutdatedSpiderMonkey|replacement=[https://firefox-source-docs.mozilla.org/js/HazardAnalysis/|]}}

== Static Analysis for Rooting and Heap Write Hazards ==

Treeherder can run two static analysis builds: the full browser (linux64-haz), just the JS shell (linux64-shell-haz). They show up on treeherder as '''H''' and '''SM(H)'''.

=== Diagnosing a hazard failure ===

The first step is to look at what sort of hazard is being reported. There are two types that cause the job to fail: stack rooting hazards for garbage collection, and heap write thread safety hazards for stylo.

The summary output will include either the string "<N> rooting hazards detected" or "<N> heap write hazards detected out of <M> allowed". See the appropriate section below for each.

=== Diagnosing a rooting hazards failure ===

Click on the '''H''' build link, select the "Job details" pane on the bottom right, follow the "Inspect Task" link, and download the "<code>public/build/hazards.txt.gz</code>" file.

Example snippet:

<pre>
Function 'jsopcode.cpp:uint8 DecompileExpressionFromStack(JSContext*, int32, int32, class JS::Handle<JS::Value>, int8**)' has unrooted 'ed' of type 'ExpressionDecompiler' live across GC call 'uint8 ExpressionDecompiler::decompilePC(uint8*)' at js/src/jsopcode.cpp:1866
js/src/jsopcode.cpp:1866: Assume(74,75, !__temp_23*, true)
js/src/jsopcode.cpp:1867: Assign(75,76, return := 0)
js/src/jsopcode.cpp:1867: Call(76,77, ed.~ExpressionDecompiler())
GC Function: uint8 ExpressionDecompiler::decompilePC(uint8*)
JSString* js::ValueToSource(JSContext*, class JS::Handle<JS::Value>)
uint8 js::Invoke(JSContext*, JS::Value*, JS::Value*, uint32, JS::Value*, class JS::MutableHandle<JS::Value>)
uint8 js::Invoke(JSContext*, JS::CallArgs, uint32)
JSScript* JSFunction::getOrCreateScript(JSContext*)
uint8 JSFunction::createScriptForLazilyInterpretedFunction(JSContext*, class JS::Handle<JSFunction*>)
uint8 JSRuntime::cloneSelfHostedFunctionScript(JSContext*, class JS::Handle<js::PropertyName*>, class JS::Handle<JSFunction*>)
JSScript* js::CloneScript(JSContext*, class JS::Handle<JSObject*>, class JS::Handle<JSFunction*>, const class JS::Handle<JSScript*>, uint32)
JSObject* js::CloneStaticBlockObject(JSContext*, class JS::Handle<JSObject*>, class JS::Handle<js::StaticBlockObject*>)
js::StaticBlockObject* js::StaticBlockObject::create(js::ExclusiveContext*)
js::Shape* js::EmptyShape::getInitialShape(js::ExclusiveContext*, js::Class*, js::TaggedProto, JSObject*, JSObject*, uint32, uint32)
js::Shape* js::EmptyShape::getInitialShape(js::ExclusiveContext*, js::Class*, js::TaggedProto, JSObject*, JSObject*, uint64, uint32)
js::UnownedBaseShape* js::BaseShape::getUnowned(js::ExclusiveContext*, js::StackBaseShape*)
js::BaseShape* js_NewGCBaseShape(js::ThreadSafeContext*) [with js::AllowGC allowGC = (js::AllowGC)1u]
js::BaseShape* js::gc::NewGCThing(js::ThreadSafeContext*, uint32, uint64, uint32) [with T = js::BaseShape; js::AllowGC allowGC = (js::AllowGC)1u; size_t = long unsigned int]
void js::gc::RunDebugGC(JSContext*)
void js::MinorGC(JSRuntime*, uint32)
GC
</pre>

This means that a rooting hazard was discovered at <code>js/src/jsopcode.cpp</code> line 1866, in the function <code>DecompileExpressionFromStack</code> (it is prefixed with the filename because it's a static function.) The problem is that they're an unrooted variable '<code>ed</code>' that holds an <code>ExpressionDecompiler</code> live across a call to <code>decompilePC</code>. "Live" means that the variable is used after the call to <code>decompilePC</code> returns. <code>decompilePC</code> may trigger a GC according to the static call stack given starting from the line beginning with "GC Function:". The hazard itself has some barely comprehensible Assume(...) and Call(...) gibberish that describes the exact path of the variable into the function call. That stuff is rarely useful -- usually, you'll only need to look at it if it's complaining about a temporary and you want to know where the temporary came from. The type '<code>ExpressionDecompiler</code>' is believed to hold pointers to GC-controlled objects of some sort. The analysis currently does not describe the exact field it is worried about.

To unpack this a little, the analysis is saying the following can happen:

* <code>ExpressionDecompiler</code> contains some pointer to a GC thing. For example, it might have a field '<code>obj</code>' of type '<code>JSObject*</code>'.
* <code>DecompileExpressionFromStack</code> is called.
* A pointer is stored in that field of the '<code>ed</code>' variable.
* <code>decompilePC</code> is invoked, which calls <code>ValueToSource</code>, which calls <code>Invoke</code>, which eventually calls <code>js::MinorGC</code>
* during the resulting garbage collection, the object pointed to by <code>ed.obj</code> is moved to a different location. All pointers stored in the JS heap are updated automatically, as are all rooted pointers. <code>ed.obj</code> is not, because the GC doesn't know about it.
* after <code>decompilePC</code> returns, something accesses <code>ed.obj</code>. This is now a stale pointer, and may refer to just about anything -- the wrong object, an invalid object, or whatever. Badness 10000, as TeX would say.

=== Diagnosing a heap write hazard failure ===

For the thread unsafe heap write analysis, a hazard means that some Gecko_* function calls, directly or indirectly, code that writes to something on the heap, or calls an unknown function that *might* write to something on the heap. The analysis requires quite a few annotations to describe things that are actually safe. This section will be expanded as we gain more experience with the analysis, but here are some common issues:

* Adding a new Gecko_* function: often, you will need to annotate any outparams or owned (thread-local) parameters in the <code>treatAsSafeArgument</code> function in <code>js/src/devtools/rootAnalysis/analyzeHeapWrites.js</code>.
* Calling some libc function: if you add a call to some random libc function (eg sin() or floor() or ceil(), though the latter two are already annotated), the analysis will report an "External Function". Add it to <code>checkExternalFunction</code>, assuming it *doesn't* have the possibility of writing to shared heap memory.
* If you call some non-returning (crashing) function that the analysis doesn't know about, you'll need to add it to <code>ignoreContents</code>.

On the other hand, you might have a real thread safety issue on your hands. Shared caches are common problems. Fix it.

=== Analysis implementation ===

These builds are performed as follows:

* run the script testing/taskcluster/scripts/builder/build-haz-linux.sh, which sets up a build environment and runs the analysis within it, then uploads the resulting files
** compile an optimized JS shell to later run the analysis
** compile the browser with gcc, using a slightly modified version of the sixgill (http://svn.sixgill.org) gcc plugin, producing a set of .xdb files describing everything encountered during the compilation
** analyze the .xdb files with scripts in js/src/devtools/rootAnalysis

=== Running the analysis ===

==== Pushing to try ====

The easiest way to run an analysis is to push to try with the trychooser line |try: -b do -p linux64-haz| (or, if the hazards of interest are contained entirely within js/src, use |try: -b do -p linux64-shell-haz| for a much faster result). The expected turnaround time for linux64-haz is just under 2 hours.

The output will be uploaded and a link named "results" will be placed into the "job details" info pane on treeherder. If the analysis fails, you will see the number of failures. Navigate to the hazards.txt.gz file.

==== Running locally ====

To run the browser analysis, you must be on a Fedora/RedHat/CentOS linux64 machine. See js/src/devtools/rootAnalysis/README.md.

If you are running Debian or Ubuntu, then there is currently a problem running the full browser analysis. You can coerce the shell-only build to work by doing something like:

sudo apt-get install autoconf2.13 libnspr4 libnspr4-dev
sudo ln -s autoconf2.13 /usr/bin/autoconf-2.13
export CFLAGS="-B/usr/lib/x86_64-linux-gnu -I/usr/include/x86_64-linux-gnu"
export CXXFLAGS="-B/usr/lib/x86_64-linux-gnu -I/usr/include/x86_64-linux-gnu"

before running the script.

=== So you broke the analysis by adding a hazard. Now what? ===

Backout, fix the hazard, or (final resort) update the expected number of hazards in js/src/devtools/rootAnalysis/expect.browser.json (but don't do that).

The most common way to fix a hazard is to change the variable to be a Rooted type, as described in http://dxr.mozilla.org/mozilla-central/source/js/public/RootingAPI.h#l21

For more complicated cases, ask on #jsapi. If you don't get a response, ping sfink or jonco for rooting hazards, bholley or sfink for heap write hazards. Or if it's a deeper issue with the analysis logic, try bhackett (the author of both analyses.)

Javascript:Hazard Builds

2021-04-28T18:22:43Z

Sfink: attempt to re-point to fx-source-docs

{{OutdatedSpiderMonkey|replacement=[https://firefox-source-docs.mozilla.org/js/HazardAnalysis/]}}

== Static Analysis for Rooting and Heap Write Hazards ==

Treeherder can run two static analysis builds: the full browser (linux64-haz), just the JS shell (linux64-shell-haz). They show up on treeherder as '''H''' and '''SM(H)'''.

=== Diagnosing a hazard failure ===

The first step is to look at what sort of hazard is being reported. There are two types that cause the job to fail: stack rooting hazards for garbage collection, and heap write thread safety hazards for stylo.

The summary output will include either the string "<N> rooting hazards detected" or "<N> heap write hazards detected out of <M> allowed". See the appropriate section below for each.

=== Diagnosing a rooting hazards failure ===

Click on the '''H''' build link, select the "Job details" pane on the bottom right, follow the "Inspect Task" link, and download the "<code>public/build/hazards.txt.gz</code>" file.

Example snippet:

<pre>
Function 'jsopcode.cpp:uint8 DecompileExpressionFromStack(JSContext*, int32, int32, class JS::Handle<JS::Value>, int8**)' has unrooted 'ed' of type 'ExpressionDecompiler' live across GC call 'uint8 ExpressionDecompiler::decompilePC(uint8*)' at js/src/jsopcode.cpp:1866
js/src/jsopcode.cpp:1866: Assume(74,75, !__temp_23*, true)
js/src/jsopcode.cpp:1867: Assign(75,76, return := 0)
js/src/jsopcode.cpp:1867: Call(76,77, ed.~ExpressionDecompiler())
GC Function: uint8 ExpressionDecompiler::decompilePC(uint8*)
JSString* js::ValueToSource(JSContext*, class JS::Handle<JS::Value>)
uint8 js::Invoke(JSContext*, JS::Value*, JS::Value*, uint32, JS::Value*, class JS::MutableHandle<JS::Value>)
uint8 js::Invoke(JSContext*, JS::CallArgs, uint32)
JSScript* JSFunction::getOrCreateScript(JSContext*)
uint8 JSFunction::createScriptForLazilyInterpretedFunction(JSContext*, class JS::Handle<JSFunction*>)
uint8 JSRuntime::cloneSelfHostedFunctionScript(JSContext*, class JS::Handle<js::PropertyName*>, class JS::Handle<JSFunction*>)
JSScript* js::CloneScript(JSContext*, class JS::Handle<JSObject*>, class JS::Handle<JSFunction*>, const class JS::Handle<JSScript*>, uint32)
JSObject* js::CloneStaticBlockObject(JSContext*, class JS::Handle<JSObject*>, class JS::Handle<js::StaticBlockObject*>)
js::StaticBlockObject* js::StaticBlockObject::create(js::ExclusiveContext*)
js::Shape* js::EmptyShape::getInitialShape(js::ExclusiveContext*, js::Class*, js::TaggedProto, JSObject*, JSObject*, uint32, uint32)
js::Shape* js::EmptyShape::getInitialShape(js::ExclusiveContext*, js::Class*, js::TaggedProto, JSObject*, JSObject*, uint64, uint32)
js::UnownedBaseShape* js::BaseShape::getUnowned(js::ExclusiveContext*, js::StackBaseShape*)
js::BaseShape* js_NewGCBaseShape(js::ThreadSafeContext*) [with js::AllowGC allowGC = (js::AllowGC)1u]
js::BaseShape* js::gc::NewGCThing(js::ThreadSafeContext*, uint32, uint64, uint32) [with T = js::BaseShape; js::AllowGC allowGC = (js::AllowGC)1u; size_t = long unsigned int]
void js::gc::RunDebugGC(JSContext*)
void js::MinorGC(JSRuntime*, uint32)
GC
</pre>

This means that a rooting hazard was discovered at <code>js/src/jsopcode.cpp</code> line 1866, in the function <code>DecompileExpressionFromStack</code> (it is prefixed with the filename because it's a static function.) The problem is that they're an unrooted variable '<code>ed</code>' that holds an <code>ExpressionDecompiler</code> live across a call to <code>decompilePC</code>. "Live" means that the variable is used after the call to <code>decompilePC</code> returns. <code>decompilePC</code> may trigger a GC according to the static call stack given starting from the line beginning with "GC Function:". The hazard itself has some barely comprehensible Assume(...) and Call(...) gibberish that describes the exact path of the variable into the function call. That stuff is rarely useful -- usually, you'll only need to look at it if it's complaining about a temporary and you want to know where the temporary came from. The type '<code>ExpressionDecompiler</code>' is believed to hold pointers to GC-controlled objects of some sort. The analysis currently does not describe the exact field it is worried about.

To unpack this a little, the analysis is saying the following can happen:

* <code>ExpressionDecompiler</code> contains some pointer to a GC thing. For example, it might have a field '<code>obj</code>' of type '<code>JSObject*</code>'.
* <code>DecompileExpressionFromStack</code> is called.
* A pointer is stored in that field of the '<code>ed</code>' variable.
* <code>decompilePC</code> is invoked, which calls <code>ValueToSource</code>, which calls <code>Invoke</code>, which eventually calls <code>js::MinorGC</code>
* during the resulting garbage collection, the object pointed to by <code>ed.obj</code> is moved to a different location. All pointers stored in the JS heap are updated automatically, as are all rooted pointers. <code>ed.obj</code> is not, because the GC doesn't know about it.
* after <code>decompilePC</code> returns, something accesses <code>ed.obj</code>. This is now a stale pointer, and may refer to just about anything -- the wrong object, an invalid object, or whatever. Badness 10000, as TeX would say.

=== Diagnosing a heap write hazard failure ===

For the thread unsafe heap write analysis, a hazard means that some Gecko_* function calls, directly or indirectly, code that writes to something on the heap, or calls an unknown function that *might* write to something on the heap. The analysis requires quite a few annotations to describe things that are actually safe. This section will be expanded as we gain more experience with the analysis, but here are some common issues:

* Adding a new Gecko_* function: often, you will need to annotate any outparams or owned (thread-local) parameters in the <code>treatAsSafeArgument</code> function in <code>js/src/devtools/rootAnalysis/analyzeHeapWrites.js</code>.
* Calling some libc function: if you add a call to some random libc function (eg sin() or floor() or ceil(), though the latter two are already annotated), the analysis will report an "External Function". Add it to <code>checkExternalFunction</code>, assuming it *doesn't* have the possibility of writing to shared heap memory.
* If you call some non-returning (crashing) function that the analysis doesn't know about, you'll need to add it to <code>ignoreContents</code>.

On the other hand, you might have a real thread safety issue on your hands. Shared caches are common problems. Fix it.

=== Analysis implementation ===

These builds are performed as follows:

* run the script testing/taskcluster/scripts/builder/build-haz-linux.sh, which sets up a build environment and runs the analysis within it, then uploads the resulting files
** compile an optimized JS shell to later run the analysis
** compile the browser with gcc, using a slightly modified version of the sixgill (http://svn.sixgill.org) gcc plugin, producing a set of .xdb files describing everything encountered during the compilation
** analyze the .xdb files with scripts in js/src/devtools/rootAnalysis

=== Running the analysis ===

==== Pushing to try ====

The easiest way to run an analysis is to push to try with the trychooser line |try: -b do -p linux64-haz| (or, if the hazards of interest are contained entirely within js/src, use |try: -b do -p linux64-shell-haz| for a much faster result). The expected turnaround time for linux64-haz is just under 2 hours.

The output will be uploaded and a link named "results" will be placed into the "job details" info pane on treeherder. If the analysis fails, you will see the number of failures. Navigate to the hazards.txt.gz file.

==== Running locally ====

To run the browser analysis, you must be on a Fedora/RedHat/CentOS linux64 machine. See js/src/devtools/rootAnalysis/README.md.

If you are running Debian or Ubuntu, then there is currently a problem running the full browser analysis. You can coerce the shell-only build to work by doing something like:

sudo apt-get install autoconf2.13 libnspr4 libnspr4-dev
sudo ln -s autoconf2.13 /usr/bin/autoconf-2.13
export CFLAGS="-B/usr/lib/x86_64-linux-gnu -I/usr/include/x86_64-linux-gnu"
export CXXFLAGS="-B/usr/lib/x86_64-linux-gnu -I/usr/include/x86_64-linux-gnu"

before running the script.

=== So you broke the analysis by adding a hazard. Now what? ===

Backout, fix the hazard, or (final resort) update the expected number of hazards in js/src/devtools/rootAnalysis/expect.browser.json (but don't do that).

The most common way to fix a hazard is to change the variable to be a Rooted type, as described in http://dxr.mozilla.org/mozilla-central/source/js/public/RootingAPI.h#l21

For more complicated cases, ask on #jsapi. If you don't get a response, ping sfink or jonco for rooting hazards, bholley or sfink for heap write hazards. Or if it's a deeper issue with the analysis logic, try bhackett (the author of both analyses.)

Template:OutdatedSpiderMonkey

2021-04-28T18:20:48Z

Sfink: First attempt at making a soft redirect (adding a `replacement` parameter.)

{| class="messagebox standard-talk" style="margin-bottom: 1em; width:100%; border:5px solid #B0C4DE; background-color:#f6f4ec;"
| rowspan="2" style="padding:0px 10px 0px;" | [[File:Ambox outdated.png|65px|link=]]
| style="padding:0px 40px 0px 10px; font-size: large; text-align:center;" | '''THIS {{#if:{{{section|}}}|SECTION|PAGE}} IS OBSOLETE'''
|-
| style="padding:0px 40px 0px 10px; text-align:left;" | This {{#if:{{{section|}}}|section|article}} is in parts, or in its entirety, outdated. {{#if:{{{replacement|}}}|The current version is at {{{replacement}}}.|}} Hence, the information presented {{#if:{{{section|}}}|under it|on this page}} may be incorrect, and should be treated with due caution. Visit [https://spidermonkey.dev/ SpiderMonkey.dev] for more up to date information.
|}<includeonly>[[Category:Outdated articles|{{PAGENAME}}]]</includeonly><noinclude>
{{documentation}}

</noinclude>

ES6 plans

2021-04-27T22:16:11Z

Sfink: caroline marked obsolete

{{OutdatedSpiderMonkey}}

== New and improved builtin APIs ==

Most of this stuff does not need to touch a lot of code. None of it requires a Harmony opt-in. This is great stuff for new contributors to start work on.

* [http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets Simple Maps and Sets] - The spec is incomplete but I will be landing what's there now in [https://bugzilla.mozilla.org/show_bug.cgi?id=697479 bug 697479].
* [http://wiki.ecmascript.org/doku.php?id=harmony:binary_data Binary data] - [https://bugzilla.mozilla.org/show_bug.cgi?id=578700 bug 578700]
* New reflection methods [http://wiki.ecmascript.org/doku.php?id=harmony:extended_object_api Object.getPropertyDescriptor, Object.getPropertyNames]
* Number.[http://wiki.ecmascript.org/doku.php?id=harmony:number.isfinite isFinite], [http://wiki.ecmascript.org/doku.php?id=harmony:number.isnan isNaN], [http://wiki.ecmascript.org/doku.php?id=harmony:number.isinteger isInteger], and [http://wiki.ecmascript.org/doku.php?id=harmony:number.tointeger toInteger]
* String.prototype.[http://wiki.ecmascript.org/doku.php?id=harmony:string.prototype.repeat repeat], [http://wiki.ecmascript.org/doku.php?id=harmony:string_extras startsWith, endsWith, contains, toArray]
* New reflection API that complements proxies: [http://wiki.ecmascript.org/doku.php?id=harmony:reflect_api harmony:reflect_api]
* [http://wiki.ecmascript.org/doku.php?id=harmony:egal Object.is]
* [http://wiki.ecmascript.org/doku.php?id=harmony:more_math_functions More math functions] - Proposed are: Math.log10, log2, log1p, expm1, cosh, sinh, tanh, acosh, asinh, atanh, hypot, trunc, sign; perhaps gamma and erf; and perhaps randomInt(n). See [https://bugzilla.mozilla.org/show_bug.cgi?id=717379 bug 717379].
* ES6 will spec that [http://wiki.ecmascript.org/doku.php?id=harmony:random-er Math.random] does not share state across multiple globals.

== New syntax (stuff that affects the front end and/or bytecode) ==

This stuff isn't terribly hard either, for the most part.

* [http://wiki.ecmascript.org/doku.php?id=harmony:iterators for-of loops] - [https://bugzilla.mozilla.org/show_bug.cgi?id=699565 bug 699565] - This is I'd say better than half done. It was easy. XPConnect must be updated so that arraylike XPCOM objects cooperate with for-of.
* [http://wiki.ecmascript.org/doku.php?id=harmony:parameter_default_values Parameter default values]
* [http://wiki.ecmascript.org/doku.php?id=harmony:rest_parameters Rest parameters] - [https://bugzilla.mozilla.org/show_bug.cgi?id=574132 bug 574132]
* [http://wiki.ecmascript.org/doku.php?id=harmony:spread Spread operator] - [https://bugzilla.mozilla.org/show_bug.cgi?id=574130 bug 574130] - The operator can appear in two places: function calls and array literals. Maybe two bugs would make sense.
* [http://wiki.ecmascript.org/doku.php?id=harmony:proper_tail_calls Proper tail calls]
* [http://wiki.ecmascript.org/doku.php?id=harmony:object_literals Extensions to object literal syntax]
* [http://wiki.ecmascript.org/doku.php?id=harmony:classes Classes]
* [http://wiki.ecmascript.org/doku.php?id=harmony:quasis Quasi-literals] [https://bugzilla.mozilla.org/show_bug.cgi?id=688857 Bug 688857]
* [http://wiki.ecmascript.org/doku.php?id=harmony:pragmas Pragmas]

== Updating SpiderMonkey extensions to the ES6 spec ==

We've implemented a ton of stuff, dating back years, that is going to be in ES6 but in a slightly different form.

=== Direct proxies ===

There is a ton of verbiage here and it is still under active development. Still, I think it should be pretty easy to implement. We already have the forwarding code. We can keep <code>Proxy.create</code> and <code>createFunction</code> without a lot of extra effort.

[https://bugzilla.mozilla.org/show_bug.cgi?id=703537 Bug 703537].

* http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies
* http://wiki.ecmascript.org/doku.php?id=harmony:proxies_spec
* http://wiki.ecmascript.org/doku.php?id=harmony:proto_climbing_refactoring
* http://wiki.ecmascript.org/doku.php?id=harmony:virtual_object_api

=== Generators and comprehensions ===

* Certain scoping details in [http://wiki.ecmascript.org/doku.php?id=harmony:array_comprehensions array comprehensions] and [http://wiki.ecmascript.org/doku.php?id=harmony:generator_expressions generator expressions] are probably different from what we have implemented.
* [http://wiki.ecmascript.org/doku.php?id=harmony:generators <code>function*</code> syntax] - [https://bugzilla.mozilla.org/show_bug.cgi?id=666399 bug 666399]
* Allow returning a value from a generator - [https://bugzilla.mozilla.org/show_bug.cgi?id=666404 bug 666404]
* There are probably one or two other minor details - details of StopIteration, that kind of thing.

=== let, const, and block functions ===

[http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings Block scoped bindings]

* Top-level let shouldn't be the same thing as var, per dherman: [https://bugzilla.mozilla.org/show_bug.cgi?id=589199 bug 589199]
* TC39 is specifying that reading a let-variable before it is initialized is an error, which will be a separate bug.
* <code>const</code> - [https://bugzilla.mozilla.org/show_bug.cgi?id=611388 bug 611388]
* Block functions - [https://bugzilla.mozilla.org/show_bug.cgi?id=585536 bug 585536] (note - opt-in only, still banned in ES5 strict mode)
* [http://wiki.ecmascript.org/doku.php?id=harmony:destructuring Destructuring]
* Per loop iteration binding of let/const.

== Harmony infrastructure ==

Some minimal steps here are a prerequisite to doing the features that require a Harmony opt-in: modules and import, block-scoped functions, <code>typeof null</code>, and lexical scoping of names declared at toplevel.

* New SM version number - This is enough to get started on harmony features with only shell tests.
* Opt-in via type="text/ecmascript;version=6" or whatever - [https://bugzilla.mozilla.org/show_bug.cgi?id=694107 bug 694107]
* Per-script opt-in syntax ('use harmony;' or whatever)
* Opt-in via HTTP header?
* Whole-page opt-in via HTML feature?

== Modules ==

[http://wiki.ecmascript.org/doku.php?id=harmony:modules harmony:modules]

Modules are [https://bugzilla.mozilla.org/show_bug.cgi?id=568953 bug 568953].

* <code>module</code> syntax, scoping semantics, module objects
* <code>import</code> syntax
* <code>from "url"</code> syntax
* Hook up <code>from "url"</code> and async module loading to Gecko
* [http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders Module loaders]

With a Harmony opt-in, programs get very different global binding behavior. The bindings are no longer shared with the global object's properties. This is a major change.

== New APIs that are in modules ==
* [http://wiki.ecmascript.org/doku.php?id=harmony:modules_standard Reorganize the standard library into modules]
* [http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects Private name objects] - [https://bugzilla.mozilla.org/show_bug.cgi?id=645416 bug 645416]
* A few functions for [http://wiki.ecmascript.org/doku.php?id=harmony:iterators iterating over object properties]

== Incompatible changes ==
Harmony may change some ES1-5 behavior, if it empirically turns out to be doable without breaking the Web.
* [http://wiki.ecmascript.org/doku.php?id=harmony:completion_reform Change how eval decides which value to return]
* typeof null == "null" with Harmony opt-in - [https://bugzilla.mozilla.org/show_bug.cgi?id=651251 bug 651251]

== Proposals that should not create any work for us ==
* [http://wiki.ecmascript.org/doku.php?id=harmony:multiple_globals Multiple globals]
* [http://wiki.ecmascript.org/doku.php?id=harmony:regexp_y_flag RegExp y (sticky) flag]
* [http://wiki.ecmascript.org/doku.php?id=harmony:regexp_match_web_reality RegExp match web reality]
* [http://wiki.ecmascript.org/doku.php?id=harmony:function_to_string Function.prototype.toString spec tweaks]

Javascript:SpiderMonkey:ES6 Testing

2021-04-27T22:10:14Z

Sfink: mark obsolete

{{OutdatedSpiderMonkey}}

= Objective =

'''Summary''': Properly test all new features and aspects of ES6.

ES6, the next iteration of ECMAScript, introduces many new features, new methods, new algorithms, and occasionally makes changes to existing methods and algorithms. Implementing these changes correctly will require a considerable number of tests for all additions and changes.

Historically most Mozilla JS tests have been self-written and work only in SpiderMonkey test harnesses. There is an effort at ECMA, test262, to introduce a standardized test format, harness, and so on, so that tests that are written can be run by any browser/engine. We should make an effort to write more tests in standardized format, so that tests we write can be used by other engines, improving the web for everyone -- even if they don't use SpiderMonkey or a Mozilla-based browser.

'''Accountable''': Naveed 
'''Responsible''': Waldo, jorendorff 
'''Consulted''': 
'''Informed''': Product Marketing

= Milestones =

<table border>
<tr>
<th>Status</th>
<th>Task</th>
<th>Deliverable</th>
<th>Assigned</th>
<th>Estimate</th>
<th>Expected</th>
<th>Actual</th>
</tr>
<tr>
<td>done</td>
<td>Get test262 running on Tinderbox</td>
<td>Test262 import script works, imports test262 tests, manually run periodically to get updates</td>
<td>Waldo</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>in progress</td>
<td>Implement <code>@negative</code> support for imported test262 tests, {{bug|496923}}</td>
<td>Most of the test262 skips in {{source|js/src/tests/jstests.list}} are removed</td>
<td>Waldo</td>
<td>1 week</td>
<td>20130823</td>
<td></td>
</tr>
<tr>
<td>in progress</td>
<td>Import the ch15 test262 tests</td>
<td>{{source|js/src/tests/test262/ch15}} exists, the tests are run on Tinderbox</td>
<td>Waldo</td>
<td>1 week</td>
<td>20130823</td>
<td></td>
</tr>
<tr>
<td>in progress</td>
<td>Process for upstreaming test262 contributions</td>
<td>Have at least one test262 contribution in {{source|js/src/tests/test262/to-upstream/}} from someone not involved in the test262 harness work</td>
<td>Waldo</td>
<td>3 days</td>
<td></td>
<td></td>
</tr>
<tr>
<td>in progress</td>
<td>Fix remaining issues preventing us from running any test262 tests</td>
<td>Only actually-failing tests skipped</td>
<td>Waldo</td>
<td>1 week</td>
<td>20130823</td>
<td></td>
</tr>
<tr>
<td>pending</td>
<td>Evaluate potential [http://wiki.ecmascript.org/doku.php?id=test262:test_case_format test262 format] changes, simplifications to ease contributions</td>
<td>Iron out test-format concerns we have that make it hard to run the tests with our shell or in the browser; scope unknown, but synchronous script inclusion from script really should go</td>
<td>Waldo</td>
<td>1 week</td>
<td></td>
<td></td>
</tr>
<tr>
<td>in progress</td>
<td>Draw up a list of the ES6 features/changes to be tested</td>
<td>Spec fully run through, all new portions listed with points of interest called out</td>
<td>Waldo</td>
<td>1 week</td>
<td></td>
<td></td>
</tr>
<tr>
<td>not started</td>
<td>Write tests for new ES6 changes</td>
<td>All areas listed below implemented</td>
<td>various</td>
<td>see below</td>
<td>see below</td>
<td></td>
</tr>

</table>

== Import the test262 suite into Mozilla, and run it on tinderbox ==

''Owner'': jwalden
''Status'': '''done'''

There's relatively little impetus for us to write test262 tests if we can't run them as often as we run all our existing tests. It should be a high priority to set up a process through which test262 tests are imported into our tree, run on each new change, and regressions flagged so that the relevant patches can be reverted.

== Fix remaining issues preventing us from running any test262 tests ==

''Owner'': jwalden 
''Status'': in progress 
''Estimate'': 1 week 

The initial test262 import was relatively brain-dead: import everything, skip tests that fail (validly or not). We need to go back and fix up our test harnesses, or the test262 import script, to run those additional tests.

Issues to fix:

* <code>@negative</code> support
* others?

== Examine the test262 test format/harness to identify any limitations in it ==

''Owner'': jwalden 
''Status'': incomplete 
''Estimate'': 1 week 

We frequently add new features and functionality to the JS shell for testing purposes. We add methods to help verify implementation internals, where adding directly to the shell makes obvious sense. But we also add functionality to make it easier to test particular bits of entirely-standard functionality -- to permit evaluating multiple global scripts in a single test, for example. We've added these features because, in our harness, this was the easiest way to test a feature. test262 doubtless has similar limitations, and as these tests must be cross-engine, it won't be possible to use Mozilla-specific helper functions.

We need to examine the test262 harness and test format and identify these limitations, and consider how they might be resolved or worked around. Note that as test262 is a shared resource, any changes we request will have to be discussed with and reviewed by non-Mozilla people to consider their effects on others, an extra bit of process that may make this take longer than it would if it were totally under our control.

== Process for upstreaming test262 contributions ==

''Owner'': jwalden 
''Status'': not started 
''Estimate'': 3 days 

Contributions to test262, going through test262, probably have too much friction to get developers to make them in the course of usual bug-fixing/regression-fixing. We should set up a {{source|js/src/tests/test262/to-upstream/}} directory into which test262-format tests can be dumped. Then whoever runs the update script can be responsible for moving them to a reasonable location, etc. and contributing them to test262. When they're landed upstream (which could be later than we want to land the patch and test in our tree), we can run the update script, pick up the new tests, and remove the to-upstream ones.

This mostly requires adding the new to-upstream directory and writing and disseminating documentation about how to write test262 tests.

== Enumerate the features/details/changes in ES6 ==

''Owner'': jwalden 
''Status'': incomplete 
''Estimate'': 4 days 

This simply requires running through ES6 drafts, as they're published, and noting things that will need testing. The following list was produced by a read-through of the ES6 spec, so it likely misses systemic interactions that need testing.

=== Ordinary/exotic objects ===

''Owner'': unowned 
''Status'': incomplete 
''Estimate'': 2 days 

* need to run through 8.4/8.5 with a fine-toothed comb looking for all the various differences
* some differences should already be tested, because they were implicit (or explicit in different form) in ES5 and earlier

=== Template literals ===

''Owner'': unowned 
''Status'': not started 
''Estimate'': unknown; depends on their being implemented, and on the implementation complexities encountered, to know what needs the most test work 

* the InputElementTemplateTail goal symbol has interesting interactions with ASI, that must be investigated
* template literals generally need to be implemented, and basic semantics tested
* testing for specific interesting characters in template literals
** Unicode format-control characters within template literals
** line terminators (Unicode and non-Unicode both)
* templates with zero or more substitution parts need particular testing

=== Binary/octal numeric literals ===

''Owner'': jwalden 
''Status'': incomplete (tested, but not in test262) 
''Estimate'': 1 day 

* implemented and tested in {{bug|894026}}
* tests need to be ported to test262 format and upstreamed

=== Non-BMP Unicode escapes ===

''Owner'': unowned 
''Status'': not started 
''Estimate'': 1 day 

* <code>\u{}</code>
* <code>\u{HexDigits}</code> is a syntax error if HexDigits > 1114111 (0x10FFFF)
* <code>\u{}</code> with a surrogate-pair number
* <code>\u{}</code> with other reserved and special code points (BOM, the reserved bits around U+FFE0 or so)

=== Identifier syntax changes ===

''Owner'': unowned 
''Status'': not started 
''Estimate'': 1 day 

* identifier goal symbols seem to have changed some -- to use the Unicode properties ID_Start and ID_Continue (and also _/$/<ZWJ>/<ZWNJ>)
* implementation may require changes to our Unicode update script, but once those changes are done, implementation should be a breeze

=== New keywords ===

''Owner'': unowned 
''Status'': not started 
''Estimate'': 1 day 

* new keywords: class, continue, const, export, import, super (possibly all reserved before, tests needed for their new semantics, and places that still forbid them)
* <code>yield</code> contextual keyword (being worked on by wingo)
* we already have tests to which keyword-checking stuff can be added (although they're not in test262 format)

=== Regular expression syntax ===

''Owner'': unowned 
''Status'': not started 
''Estimate'': unknown, depends on complexity of syntax changes 

* apparent changes here -- unclear at a glance what needs doing here

=== <code>this</code> ===

''Owner'': unowned 
''Status'': incomplete 
''Estimate'': 1 day, appears relatively short 

* 8.2.4.3 GetThisValue(V): how is this used, where, maybe needs tests (if not just some sort of refactoring of <code>this</code> keyword handling, not sure yet)

=== Property descriptors ===

''Owner'': unowned 
''Status'': not started 
''Estimate'': unknown 

* the Property Descriptor type now has an optional <nowiki>[[Origin]]</nowiki> field -- possibly/likely used for property descriptors returned from proxy hooks -- needs testing
* implementing this has interactions with the ongoing MOP refactoring work; <code>JSPropertyDescriptor</code> and/or <code>PropDesc</code> need changes for this

=== New <code><nowiki>[[HasOwnProperty]]</nowiki></code> hook ===

''Owner'': jwalden 
''Status'': incomplete 
''Estimate'': unknown 

* previously this was implicitly derived from <nowiki>[[GetOwnProperty]]</nowiki>
* implementing this has interactions with MOP refactoring
* jwalden has partial patch for that refactoring, {{bug|826587}}
* jwalden also has partial patch for the has-own-property hook, {{bug|862848}} and/or {{bug|905168}}

=== New inheritance hooks ===

''Owner'': jwalden 
''Status'': incomplete 
''Estimate'': 2 days, plus implementation time 

* needed for prototype-setting and getting to work with proxies
* we have some of this implemented already, but we don't use/respect it universally yet

=== Enumeration changes ===

''Owner'': unowned 
''Status'': not started 
''Estimate'': 1 week 

* new <nowiki>[[Enumerate]]</nowiki> and <nowiki>[[OwnPropertyKeys]]</nowiki> hooks with well-defined semantics for for(var i in o) and Object.getOwnPropertyNames/keys -- visible in proxies
* enumeration affects practically everything, so a bit of work necessary here

=== Function internal properties ===

''Owner'': unowned 
''Status'': not started 
''Estimate'': unknown 

* functions (ordinary function objects, 8.3.15.1) have a bunch more internal data properties to track -- affecting semantics in various ways; realms are perhaps the most important one (corresponding to the multiple-globals problem in web browsers)
* |new| on a function whose <nowiki>[[Prototype]]</nowiki> has been changed to null/undefined -- semantics of this are still partially up in the air
* there seems to be a requirement that <code>(function() { "use strict"; }).caller === null</code> per 8.3.15.3 which might be a change from ES5 -- needs investigation, testing, possible bug-reporting

=== <code><nowiki>[[BuiltinBrand]]</nowiki></code> ===

''Owner'': unowned 
''Status'': not started 
''Estimate'': unknown 

* used for exact-class checks from ES5 and before
* likely affects every place that currently does exact-class checks (or exact-class-modulo-other-globals checks)
* most recent ES6 draft doesn't discuss this anywhere except in overview documentation: highly under-specified right now

=== <code>String</code> objects ===

''Owner'': unowned 
''Status'': incomplete 
''Estimate'': unknown 

* String exotic objects: new internal ops defined for them, may require more testing for out-of-range -- also for negative indexes, which in the current spec seem to be passed through <code>abs()</code> (!, may be a bug)

=== Symbol exotic objects ===

''Owner'': unowned 
''Status'': not started 
''Estimate'': unknown 

* spec still in flux
* specific testing needed for "8.1.6.4 Well-Known Symbols and Intrinsics": are these directly observable, or only indirectly through spec algorithms' uses of them?
* all the hooks in 8.4.4 must be exercised, probably most simply through the <code>Reflect.*</code> methods that were (are?) mooted at one time for ES6

=== Integer Indexed exotic objects ===

''Owner'': unowned 
''Status'': incomplete 
''Estimate'': unknown 

* looks like a catch-all for typed array views, approximately

=== Declaration binding ===

''Owner'': unowned 
''Status'': not started 
''Estimate'': unknown, semantics not well-understood yet 

* addition of <code>let</code> must be accounted for
* needs careful consideration of how <code>let</code> and lexically-scoped variables interact with all this -- and also for any cases where "lexically-scoped" doesn't mean ''just'' <code>let</code> (but perhaps other things like <code>catch</code>, possibly top-level vars inside functions, function arguments, other things maybe? or not?)

=== The <code>super</code> keyword ===

''Owner'': unowned 
''Status'': not started 
''Estimate'': unknown, semantics not well-understood yet 

* used to implement "Super References (8.2.4)" -- something to do with calling superclass methods, and similar things
* will need extensive testing with all our various function/generator syntaxes
* will need testing with various methods of calling functions

=== <code>BinaryData</code> proposal ===

''Owner'': unowned 
''Status'': incomplete 
''Estimate'': unknown 

* implemented in {{bug|578700}}, ongoing bugfixing/fuzz-testing work before it'll be fully enabled
** data block type
* need to loop in nsm on this

=== Scriptable proxies ===

''Owner'': unowned 
''Status'': incomplete 
''Estimate'': unknown 

* possibly done a bit by ejpbruel?

=== <code>ToPrimitive</code> is user-hookable now ===

''Owner'': unowned 
''Status'': not started 
''Estimate'': 2 days, depends on its being implemented (which further depends on symbols) 

* ToPrimitive is now explicitly hookable in objects (doesn't use toString/valueOf properties), using a well-known symbol/intrinsic

== Other things ==

Rest of ES6 still needs to be summarized here...

= Issues =

Importing third-party tests into our tree, that we don't necessarily pass (particularly as tests for new features are introduced), requires a mechanism for marking third-party tests as failing. Ideally, this must be possible without editing the imported tests, or at least with as few edits to the imported tests as possible. It's not clear what this mechanism will look like, but it's critical that we have it.

= Risks =

test262's test format may be inadequate to test all behavior required by ES6. Tests that must run in global code, for example, may not necessarily fit into the test262 format. (This is purely my recollection from having looked into this a few years ago -- things may have changed since.) Tests which require executing multiple JS scripts (that is, through multiple <code><script></code> elements in the browser) also may pose issues. Other instances may arise over time. Dealing with these harness limitations will require adding new functionality to the harness, and may delay properly testing some new features.

ES6 is a moving target: specified features may be removed, new features may be added, changes may be made at any time. Keeping tests atop the latest spec revisions will be an ongoing challenge until ES6 is finalized (currently targeted at the end of 2014).

The test262 suite is quite large. Simply adding all test262 tests to the "J" test runs on Tinderbox will make "J" builds take a lot longer to run. It may be necessary to split test262 into its own set of builds, so that test262 can be run in parallel with the existing "J" tests. (The goal is to minimize changeset-push-to-results latency. Historically this has been accomplished mostly by running tests in parallel.) It currently appears we can import a substantial number of tests into the existing "J" builds, without unduly lengthening the time it takes to run them, so this challenge doesn't need to be immediately faced to make progress toward running test262 tests.

= Resources =

* [http://hg.ecmascript.org/tests/test262 test262 repository] (tests, harnesses, etc.)
* [http://wiki.ecmascript.org/doku.php?id=test262:test_case_format test262 test format]
* etc.
* ...

JavaScript:?Monkey

2021-04-27T22:09:47Z

Sfink: mark obsolete

{{OutdatedSpiderMonkey}}

This is a list of specific aspects of the current TraceMonkey JIT that could be improved to reduce overall JIT complexity and allow better optimization. This list (in its current form) does not determine a single specific new design but does have high-level design implications.

# Do not interleave compilation and execution
## There is a [https://bugzilla.mozilla.org/show_bug.cgi?id=561954 significant] challenge in keeping the VM state and what the compiler thinks the VM state is coherent.
## When compilation straddles execution of an op, this forces us to use the gross "pending X" pattern which makes logic non-local (e.g., bug 622318).
# Trace in terms of micro-ops instead of (current) fat-ops
## Macro-ops cause code duplication or complex factored-out helper functions
### (njn) Can you give an example? Nanojit's CSE pass removes a lot of code duplication.
#### (luke) I mean in the compiler, not in the generated code.
## Conflict: the interp/JM compiler want fat ops for performance/optimization
# Remove the "deep bail" possibility
## Deep bailing requires the programmer to maintain subtle invariants in mind at all times, especially in the presence [https://bugzilla.mozilla.org/show_bug.cgi?id=592069 macro] [https://bugzilla.mozilla.org/show_bug.cgi?id=612523 ops].
## (dvander) the problem isn't that deep bails can happen, but that they're a bad solution with a complex implementation. deep bails happen for two reasons:
### the engine has broken an invariant, and now we want to recompile, despecialize, and replace on-stack. type inference already has to do both this and maintaining the tricky sanity invariants that deep bailing did, like catching writes to properties.
### the engine wants to know something about the interpreter state. well, that's just a silly reason to deep bail :) we have to be able to reify state anyway.
# No nested trace trees: compile multiple loops
## The process of recording the call from an inner tree to outer is very delicate. Inner/outer tree reasoning is [http://hg.mozilla.org/tracemonkey/file/2b9d805d77a1/js/src/jstracer.cpp#l5236 complex].
# Compile with knowledge of multiple iterations and selectively despecialize to avoid trace explosion
## Specifically, support despecializing:
### callee (e.g., for polymorphic raytrace);
### type (e.g., for untyped data shuffling);
### shape (want ICs); and
### control flow (want non-linear traces).
## It is hard to [https://bugzilla.mozilla.org/show_bug.cgi?id=516264 simulate] with always-linear traces and knowledge of only what is happening right now.
## (dvander) despecializing types would seem to defeat the point of tracing. for data shuffling, we have to box values anyway. it might make more sense to just have a system that can hold onto boxes, and only guard on their type when the value is used by some type-dependent operation.
### The intention of the phrase "selectively despecialize" was that despecialization only occurs sometimes, so most slots/ops stay remain typed. "just have a system that can hold onto boxes" is exactly what is being called for (just not said so clearly :).

This list below is a more speculative collection of potential design decisions that address the above concerns:
* Split recording into a profiling phase followed by a more traditional compilation phase. The compilation phase consumes a data structure built by the profiling phase.
** Addresses 1 and 5
** If we want to take advantage of multi-core, this allows a clean shared-nothing hand-off of profile data from the main thread to a compilation thread.
* Keep the existing bytecode/IR; define a new micro-op IR and a decomposition function that maps a single fato-ops into a set of micro-ops.
** Resolves conflict 2.2
** Don't have to rewrite parser, decompiler, mjit, type inference, etc.
** May be slow if profiling was done from an interpreter; perhaps let the mjit compiler or a special profiling compiler compile functions with profiling instrumentation.
*** (dmandelin) I don't understand the above point. I think the sentence wants to say "let the mjit compiler or a special profiling compiler compile functions with profiling instrumentation", but I'm not sure. Anyway, I'm not sure about that. We know that we can do 100-400 iters in an interpreter in the time it takes to compile, so if profiling requires fewer runs than that, we should just do it in the interpreter, or a special profiling interpreter.
**** (luke) Good point; this was written before the 100-400 figure which certainly seems to indicate that we can profile for a while.
** Can define simple "definitional interpreter" for micro-ops that would (1) help new hackers (2) help isolate bugs in other execution modes.
** (dmandelin) I think we should think about long-term goals too. Ideally, I would shoot for a "primary" bytecode that helps simplify the compilers as much as possible. I think that would be a thin-op bytecode with an unlimited number of virtual registers. (That may be too far, though--the interpreter would certainly require a register-assignment lowering pass on top of such a thing and we need to keep startup cheap.)
*** Now, we can't take the time to overhaul that right now, so for next year I'm with you.
*** But we should at least have a viable path there, and make what steps we can in that direction.
* To avoid deep bails:
** Have the tracer execute in-place instead of in TraceNativeStorage ([https://bugzilla.mozilla.org/show_bug.cgi?id=590871 bug 590871])
*** (dmandelin) I think this means "do it like the mjit does", i.e., hold stuff in registers and so on, but know how to save out to the canonical representation at safe points.
**** Not exactly; more like "do it like the tjit, just on the VM stack, using the VM layout instead of on some separate hunk o' memory (TraceNativeStorage) with a custom layout (VistFrameSlots)"
** Assume every native called from jit code clobbers globals and visible upvars except those explicitly annotated not to do so in their JSNativeTraceInfo.
*** Thus, if VM reenters or VM state is modified during call from trace, no assumptions are broken.
*** Rely on (1) type inference results and (2) redundant-guard elimination to keep computational kernels fast and unfettered.

JavaScript:Projects

2021-04-27T22:09:28Z

Sfink: mark obsolete

{{OutdatedSpiderMonkey}}

This list of active JS projects was compiled from older lists of [https://wiki.mozilla.org/JavaScript:Home_Page#Tracked_Projects tracked projects] and [https://wiki.mozilla.org/Javascript:SpiderMonkey:2013Projects 2013 projects].

= JavaScript Language =

== Parallel JS ==
* '''Goal:''' Expose finer-grain parallelism to JavaScript.
* '''Team:''' sstangl, luke, niko, shu?
* '''Tracking bug:''' {{bug|891877}}
* '''More info:''' Work includes a parallel subset of JS ({{bug|891877}}), RiverTrail/ParallelArray ({{bug|801869}}), and prototyping Shared ArrayBuffers.

== ECMA-402 i18n ==
* '''Goal:''' Implement ECMA-402, the ECMAScript Internationalization API.
* '''Developer:''' jwalden
* '''Tracking bug:''' {{bug|837963}}
* '''More info:''' https://wiki.mozilla.org/User:Waldo/Internationalization_API

== Test262 ==
* '''Goal:''' Integrate test262, ECMA's ECMAScript conformance test suite, into Mozilla's tests ({{bug|496923}}) and fix failures ({{bug|652780}}).
* '''Developer:''' jwalden
* '''Tracking bug:''' {{bug|496923}}
* '''More info:''' https://wiki.mozilla.org/User:Waldo/ES6_testing and http://test262.ecmascript.org/

== ES6 ==
* '''Goal:''' Implement ES6 language support.
* '''Team:'''
* '''Tracking bug:''' {{bug|694100}}
* '''More info:''' https://wiki.mozilla.org/ES6_plans

=== Classes ===
* '''Goal:''' Implement classes.
* '''Team:'''
* '''Tracking bug:''' {{bug|837314}}
* '''More info:''' http://wiki.ecmascript.org/doku.php?id=harmony:classes

=== Modules ===
* '''Goal:''' Implement modules.
* '''Team:''' Eddy and Jason?
* '''Tracking bug:''' {{bug|568953}}
* '''More info:''' http://wiki.ecmascript.org/doku.php?id=harmony:modules

=== Symbols ===
* '''Goal:''' Implement symbols (formerly private name objects).
* '''Team:''' Eddy
* '''Tracking bug:''' {{bug|645416}}
* '''More info:''' http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects

=== Typed Objects ===
* '''Goal:''' Implement typed objects (formerly binary objects) for efficient, structured access to contiguously allocated data.
* '''Team:''' Nikhil, Niko?
* '''Tracking bug:''' {{bug|578700}}
* '''More info:''' http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects

= GC =

== Generational GC ==
* '''Goal:''' Implement generational garbage collector (GGC) and exactly root Firefox.
* '''Team:''' terrence, sfink, jonco
* '''Tracking bug:''' GGC {{bug|619558}} and Exact Stack Rooting {{bug|753203}}
* '''More info:''' https://wiki.mozilla.org/Javascript:SpiderMonkey:ProjectGenerationGarbageCollection and [https://people.mozilla.org/~sfink/analysis/ rooting hazard burndown chart]

== Memory-dependent GC Configuration ==
* '''Goal:'''
* '''Team:''' TBD
* '''Tracking bug:''' TBD
* '''More info:''' Currently the GC settings are configured for Unagi devices with 256 MB, and even if this is our current target in terms of Market, but we would need to generalize our GC settings to perform best on all devices (see Bug 898556). Even with GGC, we might still have frequenct GCs if we overflow the nursery before the next minor GC.

== Future ==
* Incremental Browser Marking
* Compacting GC
* Nursery allocation of JSStrings
* G1: The Good Parts {{bug|902174}}
* Concurrent GC

= Performance =

== ARM/B2G ==
* '''Goal:''' Optimize ARM performance for Firefox OS and Android.
* '''Team:''' dcrosher, jcoppeard, mrosenberg
* '''Tracking bug:''' {{bug|}}
* '''More info:'''

== AWFY ==
* '''Goal:''' Optimize AWFY benchmarks.
* '''Team:'''
* '''Tracking bug:''' {{bug|}}
* '''More info:''' http://arewefastyet.com/

== OdinMonkey ==
* '''Goal:''' Optimize OdinMonkey and Emscripten.
* '''Team:''' luke, alon
* '''More info:''' https://wiki.mozilla.org/Javascript:SpiderMonkey:OdinMonkey
** Visual Studio integration with Emscripten - Naveed waiting on contractor SOW

== Web Browser Grand Prix ==
* '''Goal:''' Beat Chrome on Tom's Hardware's Web Browser Grand Prix (WBGP). Run Peacekeeper, Browsermark, and JSBench benchmarks in-house.
* '''Team:''' Naveed
* '''Tracking bug:''' {{bug|499198}}, {{bug|851699}}
* '''More info:''' http://browsermark.rightware.com/

== Selenium Browser Benchmark ==
* '''Goal:''' Create a test framework to browse real websites using Selenium scripts and measure performance regressions.
* '''Team:''' jmaher, bclary, luke
* '''Tracking bug:''' {{bug|}}
* '''More info:''' The A-Team is implementing this test framework with input from Luke. https://etherpad.mozilla.org/js-benchmarking

== Start-up Cache ==
* '''Goal:''' Cache JS bytecode as "extra data" for B2G apps. The target would be to land with support of packaged app for B2G 1.4 / 1.5 (Gecko 30 / 32).
* '''Team:''' npierron
* '''Tracking bug:''' {{bug|900784}}
* '''More info:''' https://wiki.mozilla.org/Javascript:SpiderMonkey:StartupCache

= Dev Tools =

== jsdbg2 ==
* '''Goal:''' Add profiling API ({{bug|797876}}) and JIT stack debugging ({{bug|716647}}) jsdbg2, then remove JSD1 ({{bug|800200}}).
* '''Team:''' TBD
* '''Tracking bug:''' {{bug|800200}}
* '''More info:'''

= Technical Debt =

== Run TBPL Tests On All Platforms ==
* '''Goal:''' Get our existing test suites running on TBPL in all combinations of the shell and browser on both desktop and ARM.
* '''Team:'''
* '''Tracking bug:''' {{bug|}}
* '''More info:'''

== Minimize Header Dependencies ==
* '''Goal:''' Reduce header dependencies of jsapi.h and friends to improve rebuild times.
* '''Team:''' njn
* '''Tracking bug:''' {{bug|908050}}
* '''More info:''' {{bug|785103}} tracks header minimization for all of Gecko.

== Refactor MOP ==
* '''Goal:''' Update meta-object protocol to be more ES5/ES6-like.
* '''Team:''' jwalden
* '''Tracking bug:''' MOP {{bug|637378}} and property/element {{bug|586842}}
* '''More info:''' https://wiki.mozilla.org/Javascript:SpiderMonkey:PropertyElementStorage

== Remove JSContext ==
* '''Goal:''' The single-threaded JSRuntime makes JSContext unnecessary, but most of the work is to make Gecko stop depending on them ({{bug|767938}}).
* '''Team:'''
* '''Tracking bug:''' JSContext {{bug|650361}} and Gecko {{bug|767938}}
* '''More info:'''

= Research =

== Shumway ==
* '''Goal:''' Add built-in SWF support to Firefox with Shumway.
* '''Team:''' mbebenita, shu, till, tobeytailor, ydelendik
* '''Tracking bug:''' {{bug|904346}}
* '''More info:''' http://www.areweflashyet.com/

JavaScript

2021-04-27T20:46:30Z

Sfink: nuke the old content

Are you looking for documentation about the JavaScript language? You probably want the [https://developer.mozilla.org/docs/Web/JavaScript Mozilla Developer Network JavaScript site].

For SpiderMonkey, the JavaScript engine that powers Firefox, see [https://spidermonkey.dev/ SpiderMonkey.dev].

JavaScript:SpiderMonkey:Coding Style

2019-06-10T17:33:45Z

Sfink: /* Functions */ namespaces

= Code Organization =

See [[JavaScript:SpiderMonkey:Directories]].

= Functions =

* Public function names go into the JS namespace, with the function name "intercaps", e.g. JS_NewObject.
** Older functions may begin with JS_. Use the namespace instead in new code.
* Extern but library-private function names use the js namespace and mixed case, e.g. js_SearchScope.
* Most static function names have unprefixed, mixed-case names: GetChar.
* But static native methods of JS objects have lowercase, underscore-separated or intercaps names, e.g., str_indexOf.
* Function return types are on a separate line preceding the function name.
* Function braces go on the line following the function name.
void DoThis() /* bad */
{
...
}
void
DoThis() /* OK */
{
...
}

= Other Symbols =

* Library-private and static data use underscores, not intercaps (but library-private data do use a js_ prefix).
* Scalar type names are lowercase and js-prefixed: jsdouble.
* Aggregate type names are JS-prefixed and mixed-case: JSObject.
* Macros are generally ALL_CAPS and underscored, to call out potential side effects, multiple uses of a formal argument, etc. Line continuation characters should all line up, in column 79 if that exceeds the width of all the macro text. Macro parameters should be of the form name_ (instead of something like __name).

= Indentation =

* Use spaces, not tabs. There should be no tabs in source files.
* Four spaces of indentation per statement nesting level.
* "<code>case L:</code>" labels in <code>switch</code> statements count as half of a nesting level, so indent two spaces, with the labeled statements indenting two more for a standard four spaces indentation from <code>switch</code> to a case-controlled statement.
switch (discriminant) {
case L1:
DoSomething();
. . .
}
* Function arguments that overflow the first line of the call expression should be aligned to underhang the first argument (to start in overflow lines in the column after the opening parenthesis).
JS_SetContext(rt, /* bad */
cx);
JS_SetContext(rt, /* OK */
cx);

= Whitespace in declarations =

These rules are inconsistently applied. Be consistent with the code you're editing rather than adhere too closely to these guidelines!

* In a declaration of a pointer, the <code>*</code> goes with the type:
char *s; /* bad */
char* s; /* OK */
* In C++ method declarations with default arguments, use spaces and comments like so:
static void
Frob(JSContext* cx, uint32_t defaultValue = 0);
static void
Frob(JSContext* cx, uint32_t defaultValue /* = 0 */)
{
/* ... */
}

= Other whitespace =

* Code should fit within 99 columns; comments should fit within 80 columns; both figures include indentation. Break down lines that are too long by splitting after a binary operator.
* Exception: in a <code>switch</code> statement where each case is a trivially-short statement, it's ok to put the <code>case</code>, the statement, and the <code>break;</code> all on one line.
* Comment <code>/* FALL THROUGH */</code> in place of missing <code>break</code> when intentionally falling through from one case-controlled statement sequence into another, or into the <code>default</code> statements.
* Do not use spaces between a function name and its arguments list, or between an array name and the square bracket. Also, do no use spaces after a bracket. Use a space after a comma to separate arguments.
JS_SetContext ( rt, cx ); /* bad */
JS_SetContext(rt, cx); /* OK */
* Use a space between a C keyword and parentheses.
if(condition) { /* bad */
if (condition) { /* OK */
* Always use braces for conditionals, even if the condition and consequent occupy single lines.

if (!isAwake) {
return false;
}
if (canSwingFromWeb) {
p->swingFromWeb();
} else {
MOZ_ASSERT(p->isSpiderPig());
p->doWhateverSpiderPigDoes();
}
if (hungryForBananas && // and a comment makes the line long enough for a linebreak
wantsAttentionInTheWorstWay)
{
p->eatBananasAndPreen();
}
* Conditions with multi-line tests should put the brace on the new line to provide a visual separation between the condition and the body.

types::TypeSet* types = frame.extra(lhs).types;
if (JSOp(*PC) == JSOP_SETPROP && id == types::MakeTypeId(cx, id) &&
types && !types->unknownObject() &&
types->getObjectCount() == 1 &&
types->getTypeObject(0) != nullptr &&
!types->getTypeObject(0)->unknownProperties())
{
JS_ASSERT(usePropCache);
types::TypeObject* object = types->getTypeObject(0);
types::TypeSet* propertyTypes = object->getProperty(cx, id, false);
...
} else {
...
}
However, if there is already a visual separation between the condition and the body, putting the { on a new line isn't necessary:

if (forHead->pn_kid1 && NewSrcNote2(cx, cg, SRC_DECL,
(forHead->pn_kid1->isOp(JSOP_DEFVAR))
? SRC_DECL_VAR
: SRC_DECL_LET) < 0) {
return false;
}
* <code>for</code> loop heads go on one line where possible; when not possible, initializer part, update, and termination parts each go on separate lines
for (int i = 0;
i < 5;
i++) { /* bad, could all fit on one line */
doStuff();
}
for (int i = 0; i < 5; i++) { /* OK */
doStuff();
}
for (size_t ind = JSObject::JSSLOT_DATE_COMPONENTS_START;
ind < JSObject::DATE_FIXED_RESERVED_SLOTS; ind++) { /* bad */
obj->setSlot(ind, DoubleValue(utcTime));
}
for (size_t ind = JSObject::JSSLOT_DATE_COMPONENTS_START;
ind < JSObject::DATE_FIXED_RESERVED_SLOTS;
ind++) { /* OK */
obj->setSlot(ind, DoubleValue(utcTime));
}
* In comments, use one space, not two, between sentences and after a colon.

= Control Flow =

* Minimize indentation using return, break, and continue where appropriate. Prefer return (break, continue) statements to cast out abnormal cases, instead of nesting "if/else" statements and indenting the common cases.
void
MyFunction(int n)
{
if (n) { /* bad */
...
}
}
void
MyFunction(int n)
{
if (!n) {
return; /* OK */
}
...
}

* If an "if" statement controls a "then" clause ending in a return statement, do not use "else" after return.
if (condition) { /* bad */
DoThis();
return;
} else {
DoThat();
}

if (condition) { /* OK */
DoThis();
return;
}
DoThat();

* Avoid similar arbitrary patterns and non-sequiturs:
if (condition) { /* bad */
DoThis();
DoThat();
} else {
CleanUp();
return;
}
DoTheOther();
if (!condition) { /* OK */
CleanUp();
return;
}
DoThis();
DoThat();
DoTheOther();

* Avoid using && or || to mix deciding-whether-to-do-something with error-checking.

if (obj->hasProblems() && !obj->rectify()) { /* bad */
return false;
}

if (obj->hasProblems()) { /* OK */
if (!obj->rectify()) {
return false;
}
}

= Comments =

* In C files, always use C style comments. C++ comments are ok otherwise.
* Terminate a comment with a period (so try to make comments be complete sentences).
/* This is a good comment. */
// This is also a good comment.
* For C-style multiline comments, align with any indentation, and start every line with an asterisk. Asterisks stack in the same column. Precede the multiline comment with one empty line unless the prior line ends in a left brace. The first line of the comment contains only leading space followed by <code>/*</code>. Multiline comments should also be bracketed.
<pre>
if (condition) {
/*
* This is a lengthy C-style
* multiline comment.
*/
// This is a length
// C++-style comment
DoYourStuff();
}
</pre>

= Entry Points and Callbacks =

* DLL entry points have their return type expanded within a JS_PUBLIC_API() macro call, to get the right Windows secret type qualifiers in the right places for all build variants.
* Callback functions that might be called from a DLL are similarly macroized with JS_STATIC_DLL_CALLBACK (if the function otherwise would be static to hide its name) or JS_DLL_CALLBACK (this macro takes no type argument; it should be used after the return type and before the function name).

= Data Types and Alignments =

* As with all Mozilla code, SpiderMonkey needs to compile and execute correctly on many platforms, including 64-bits systems.
* JS and NSPR have common roots in the dawn of time (Netscape 2), and the <code>JS_THREADSAFE</code> mode of building SpiderMonkey depends on NSPR, so reading the [http://www.mozilla.org/projects/nspr/reference/html/ NSPR documentation] is well worth your while.
* Not all 64-bit systems use the same integer type model: some are "LP64" (long and pointer are 64 bits, int is 32 bits), while others are "LLP64" (only long long and pointer are 64 bits; long and int are 32 bits).
* Use size_t for unsigned number of bytes variables, ptrdiff_t for signed pointer subtraction results. In particular, do not use uintN, which is just shorthand for unsigned int, and so may not be big enough.

= Header files =

== #ifndef wrappers ==

Use this exact form for #ifndef wrappers in header files:

#ifndef <guard>
#define <guard>
...
#endif // <guard>

GCC and clang recognize this idiom and avoid re-reading headers that use it. Don't put any code before the #ifndef or after the #endif, and don't put anything else in the #ifndef, otherwise the optimization will be thwarted and the file will be multiply-included. (Check with the -H option if you want to be sure.)

Include guards should be named by determining the fully-qualified include path,
then substituting _ for '/' and '.' and '-' in it. For example, js/src/vm/Stack-inl.h's guard is vm_Stack_inl_h_, and js/public/Vector.h's guard is js_Vector_h (because its include path is js/Vector.h).

== #include paths ==

All #include statements should use a fully-qualified (within SpiderMonkey) path, even if it's not necessary. For example, this:

#include "vm/Stack.h"

not:

#include "Stack.h"

This keeps things consistent and helps with the ordering.

For headers in js/public/, the prefix is "js/", e.g.:

#include "js/Vector.h"

For headers in mfbt/, the prefix is "mozilla/", e.g.:

#include "mozilla/Assertions.h"

== #include ordering ==

The following order is used for module X:
* If X-inl.h exists, it goes first. (And X-inl.h's first #include should be X.h.) Otherwise, X.h goes first. This rule ensures that X.h and X-inl.h both #include all the headers that they need themselves.
* mozilla/*.h
* <*.h>
* js*.h
* */*.h (this includes the public JSAPI headers in js/public/*.h which should be included using the form js/*.h)
* js*inlines.h
* */*-inl.h.

Keep (case-insensitive) lexicographic order with each section.

The presence of conditionally-compiled #include statements complicates thing. If you have a single #include statement within a #if/#ifdef/#ifndef block, placing the block in the appropriate section is straightforward. If you have multiple #include statements within a block, use your judgment as to where the best place for it is.

Example for X.cpp:

#include "X.h" // put "X-inl.h" instead, if it exists

#include "mozilla/HashFunctions.h"

#include <string.h>

#include "jsbar.h"
#ifdef BAZ
# include "jsbaz.h"
#endif
#include "jscaz.h"

#include "ds/Baz.h"
#include "js/Bar.h"
#include "vm/Bat.h"

#include "jssqueeinlines.h"
#include "jswoot-inl.h"

#include "frontend/Thingamabob-inl.h"
#include "vm/VirtualReality-inl.h"

= C++ =

== Namespaces ==

* Public functions and types should be in the JS:: namespace, in preference to the old JS/JS_ name prefixes.
* Library-private and friend functions should be in the js:: namespace, in preference to the old js_ name prefix.
* Compile-time-evaluated functions (i.e., template meta-functions) should be in 'js::tl::', the "template library" namespace, to avoid collision with their runtime counterparts.
* In SpiderMonkey .cpp files, it is okay to have 'using namespace js;', but it is not okay to do the same with any other namespace, like JS:: or mozilla::. These can introduce ambiguities that come and go depending on which .cpp files the build system decides to unify.
* If you do have names in JS:: that should be readily available throughout SpiderMonkey, you may add a 'using' declaration to js/src/NamespaceImports.h.
* Avoid unnamed namespaces unless they are necessary to give a class's members internal linkage. Although the C++ standard officially deprecates 'static' on functions, 'static' has the following advantages over unnamed namespaces:
** It is difficult to name functions in unnamed namespaces in gdb.
** Static says "this is a translation-unit-local helper function" on the function, without having to look around for an enclosing "namespace {".

== Enums ==

Older code uses SHOUT_REALLY_LOUD for enum values, newer code uses InterCaps. Enums should be preferred to boolean arguments for ease of understanding at the invocation site.

== Classes ==

* For reasonable-sized classes, put all the fields together, at the top, immediately after any necessary typedefs. For unreasonably large classes, do whatever seems best (but let's try to avoid making more of these).
* Align the braces of a class/struct/enum definition like this:
class JSObject
{
...
};
* Member variable names, private or public, should be decorated with a trailing '_'.
class Fail
{
size_t capacity; // common
T* begin_; // better, gravitate toward this
};
Sometimes a canonical argument name may conflict with a member name. In this case, one can disambiguate with "this->", although such explicit qualification should only be added when necessary:
class C
{
public:
size_t count;
bool fresh;
void change(size_t count) {
this->count = count;
this->fresh = false; // verbose and unnecessary
}
};
* Prefer inline functions to macros.
* We build with C++ exceptions disabled, so most of the <code>std</code> namespace is off-limits, including STL containers. The exception is <code><algorithm></code>, which is mostly OK to use. You can use MFBT. We have some STL-like containers that are used basically everywhere (see js::Vector, js::HashMap, etc.)

=== Initializer lists ===

Initializer lists can break in one of two ways. The first may be preferable when constructors take few arguments:

class Ninja : public WeaponWeilder, public Camouflagible,
public Assassinatable, public ShapeShiftable
{
Ninja() : WeaponWeilder(Weapons::SHURIKEN),
Camouflagible(Garments::SHINOBI_SHOZOKU),
Assassinatable(AssassinationDifficulty::HIGHLY_DIFFICULT),
ShapeShiftable(MPCost(512)) {}
}

The other permitted style mitigates longer-identifiers-squishing-text-against-the-right-side-of-the-screen-syndrome by using a half-indented colon:

class Ninja
: public WeaponWeilder, public Camouflagible, public Assassinatable,
public ShapeShiftable
{
Ninja()
: WeaponWeilder(Weapons::SHURIKEN),
Camouflagible(Garments::SHINOBI_SHOZOKU),
Assassinatable(AssassinationDifficulty::HIGHLY_DIFFICULT),
ShapeShiftable(MPCost(512)) {}
}

=== Inline methods ===

If the method in question fits on one line and is branch free, do a one liner:

class Eater
{
void eat(Eaten &other) { other.setConsumed(); }
};

If it's too long, put the type, declarator including formals (unless they overflow), and left brace all on the first line:

class Eater
{
Food* obtainFoodFromEatery(Eatery& eatery) {
if (!eatery.hasFood()) {
return nullptr;
}
return eatery.purchaseFood();
}
};

For out-of-line inlines (when the definitions are too unwieldy to place in the class definition) use the inline keyword as an indicator that there's an out-of-line inline definition:

class SpaceGoo
{
inline BlobbyWrapper* enblob(Entity& other);
};

inline BlobbyWrapper*
SpaceGoo::enblob(Entity &other)
{
/* ... */
}

== References ==

* [https://developer.mozilla.org/en/Mozilla_Coding_Style_Guide Mozilla's coding style guide].
* [http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml Google's C++ coding style guide].

= Exceptions to this coding style =

SpiderMonkey contains some code imported from other projects, e.g. ctypes/libffi/, that is minimally modified. Such code does not have to follow SpiderMonkey style.

WeeklyUpdates

2019-05-31T20:58:24Z

Sfink: /* Meeting Notes */ added next mtg

:''Mozilla weekly all-hands meetings. For the semi-annual meetings see [[All Hands]]. These updates concern Mozilla as a whole. For the weekly Firefox meetings, see [[Firefox/DeliveryMeetings]], for Gecko progress, see [[Platform#Meeting_Notes]].''

==Meeting Details==
*Every Monday @ 11:00am Pacific Time (18:00 UTC)
*Mozilla HQ, Ten Forward commons area
{{conf|8600}}
*http://air.mozilla.org/ to watch and listen
*join #weekly-project-call on irc.mozilla.org or Slack for backchannel discussion
*'''Presenters only''': Vidyo room "Brownbags". Do ''not'' use this room if you're not planning to speak.

'''Agenda:''' [[WeeklyUpdates/{{#time: Y-m-d | monday}}|Next Week's Agenda]]

When you call in, you'll be muted by default, to keep phone noise doMwn. Use "*1" (including the star) to unmute yourself if you want to say something.

Full notes below. 

==Meeting Notes==
[[Template:WeeklyUpdates]] - <nowiki>{{subst:WeeklyUpdates}}</nowiki>


Create a new weekly agenda from the [[Template:WeeklyUpdates|template]]:
<createbox>
align=left
type=create
preload=Template:WeeklyUpdates
default={{#time: Y-m-d | monday}}
prefix=WeeklyUpdates
</createbox>

{| class="wikitable collapsible collapsed" style="width: 100%"
! 2019
|-
|
* [[WeeklyUpdates/2019-06-03|June 3rd, 2019]]
* May 27th, 2019 (No Meeting Due to Memorial Day US Holiday)
* [[WeeklyUpdates/2019-05-20|May 20th, 2019]]
* [[WeeklyUpdates/2019-05-13|May 13th, 2019]]
* [[WeeklyUpdates/2019-05-06|May 6th, 2019]]
* [[WeeklyUpdates/2019-04-29|April 29nd, 2019]]
* [[WeeklyUpdates/2019-04-22|April 22nd, 2019]]
* [[WeeklyUpdates/2019-04-15|April 15th, 2019]]
* [[WeeklyUpdates/2019-04-08|April 8th, 2019]]
* [[WeeklyUpdates/2019-04-01|April 1st, 2019]]
* [[WeeklyUpdates/2019-03-25|March 25th, 2019]]
* [[WeeklyUpdates/2019-03-18|March 18th, 2019]]
* [[WeeklyUpdates/2019-03-11|March 11th, 2019]]
* [[WeeklyUpdates/2019-03-04|March 4th, 2019]]
* [[WeeklyUpdates/2019-02-25|February 25th, 2019]]
* February 18th, 2019 (No meeting due to Washington's Birthday US Holiday)
* [[WeeklyUpdates/2019-02-11|February 11th, 2019]]
* [[WeeklyUpdates/2019-02-04|February 4th, 2019]]
* [[WeeklyUpdates/2019-01-28|January 28th, 2019]]
* January 21th, 2019 (No meeting due to Martin Luther King Jr. Day in the US)
* [[WeeklyUpdates/2019-01-14|January 14th, 2019]]
* [[WeeklyUpdates/2019-01-07|January 7th, 2019]]
|}

{| class="wikitable collapsible collapsed" style="width: 100%"
! 2018
|-
|
* [[WeeklyUpdates/2018-12-17|December 17th, 2018]]
* [[WeeklyUpdates/2018-12-10|December 10th, 2018]] (no meeting, people flying home from [[All_Hands/Orlando2018|Mozlando2018]]!)
* [[WeeklyUpdates/2018-12-03|December 3rd, 2018]] (no meeting, see you at [[All_Hands/Orlando2018|Mozlando2018]]!)
* [[WeeklyUpdates/2018-11-26|November 26th, 2018]]
* [[WeeklyUpdates/2018-11-19|November 19th, 2018]]
* [[WeeklyUpdates/2018-11-12|November 12th, 2018]]
* [[WeeklyUpdates/2018-11-05|November 5th, 2018]]
* [[WeeklyUpdates/2018-10-29|October 29nd, 2018]]
* [[WeeklyUpdates/2018-10-22|October 22nd, 2018]]
* [[WeeklyUpdates/2018-10-15|October 15th, 2018]]
* [[WeeklyUpdates/2018-10-08|October 8th, 2018]]
* [[WeeklyUpdates/2018-10-01|October 1st, 2018]]
* [[WeeklyUpdates/2018-09-24|September 24th, 2018]]
* [[WeeklyUpdates/2018-09-17|September 17th, 2018]]
* [[WeeklyUpdates/2018-09-10|September 10th, 2018]]
* [[WeeklyUpdates/2018-09-03|September 3rd, 2018]] (no meeting, US Holiday)
* [[WeeklyUpdates/2018-08-27|August 27th, 2018]]
* [[WeeklyUpdates/2018-08-20|August 20th, 2018]]
* [[WeeklyUpdates/2018-08-13|August 13th, 2018]]
* [[WeeklyUpdates/2018-08-06|August 6th, 2018]]
* [[WeeklyUpdates/2018-07-30|July 30th, 2018]]
* [[WeeklyUpdates/2018-07-23|July 23rd, 2018]]
* [[WeeklyUpdates/2018-07-16|July 16th, 2018]]
* [[WeeklyUpdates/2018-07-09|July 9th, 2018]]
* [[WeeklyUpdates/2018-07-02|July 2nd, 2018]]
* [[WeeklyUpdates/2018-06-25|June 25th, 2018]]
* June 18th, 2018 - no meeting (post-All Hands San Francisco)
* June 11th, 2018 - no meeting (All Hands San Francisco)
* [[WeeklyUpdates/2018-06-04|June 4th, 2018]]
* May 28th, 2018 - no meeting (US holiday)
* [[WeeklyUpdates/2018-05-21|May 21st, 2018]]
* [[WeeklyUpdates/2018-05-14|May 14th, 2018]]
* [[WeeklyUpdates/2018-05-07|May 7th, 2018]]
* [[WeeklyUpdates/2018-04-30|April 30th, 2018]]
* [[WeeklyUpdates/2018-04-23|April 23rd, 2018]]
* [[WeeklyUpdates/2018-04-16|April 16th, 2018]]
* [[WeeklyUpdates/2018-04-09|April 9th, 2018]]
* [[WeeklyUpdates/2018-04-02|April 2nd, 2018]]
* [[WeeklyUpdates/2018-03-26|March 26th, 2018]]
* [[WeeklyUpdates/2018-03-19|March 19th, 2018]]
* [[WeeklyUpdates/2018-03-12|March 12th, 2018]]
* [[WeeklyUpdates/2018-03-05|March 5th, 2018]]
* [[WeeklyUpdates/2018-02-26|February 26th, 2018]]
* [[WeeklyUpdates/2018-02-12|February 12th, 2018]]
* [[WeeklyUpdates/2018-02-05|February 5th, 2018]]
* [[WeeklyUpdates/2018-01-29|January 29th, 2018]]
* [[WeeklyUpdates/2018-01-22|January 22nd, 2018]]
* January 15th, 2018 (No meeting due to Martin Luther King Jr. Day in the US)
* [[WeeklyUpdates/2018-01-08|January 8th, 2018]]
|}

{| class="wikitable collapsible" style="width: 100%"
! 2017
|-
|
* [[WeeklyUpdates/2017-12-04|December 4th, 2017]]
* [[WeeklyUpdates/2017-11-27|November 27th, 2017]]
* [[WeeklyUpdates/2017-11-20|November 20th, 2017]]
* [[WeeklyUpdates/2017-11-13|November 13th, 2017]]
* [[WeeklyUpdates/2017-11-06|November 6th, 2017]]
* [[WeeklyUpdates/2017-10-30|October 30th, 2017]]
* [[WeeklyUpdates/2017-10-23|October 23th, 2017]]
* [[WeeklyUpdates/2017-10-16|October 16th, 2017]]
* [[WeeklyUpdates/2017-10-09|October 9th, 2017]]
* [[WeeklyUpdates/2017-10-02|October 2nd, 2017]]
* [[WeeklyUpdates/2017-09-25|September 25th, 2017]]
* [[WeeklyUpdates/2017-09-18|September 18th, 2017]]
* [[WeeklyUpdates/2017-09-11|September 11th, 2017]]
* [[WeeklyUpdates/2017-08-28|August 28th, 2017]]
* [[WeeklyUpdates/2017-08-21|August 21th, 2017]]
* [[WeeklyUpdates/2017-08-14|August 14th, 2017]]
* [[WeeklyUpdates/2017-08-07|August 7th, 2017]]
* [[WeeklyUpdates/2017-07-31|July 31st, 2017]]
* [[WeeklyUpdates/2017-07-24|July 24th, 2017]]
* [[WeeklyUpdates/2017-07-17|July 17th, 2017]]
* [[WeeklyUpdates/2017-07-10|July 10th, 2017]]
* July 3rd, 2017 (No meeting due to All-Hands SF Recovery)
* June 26th, 2017 (No meeting due to All-Hands SF)
* [[WeeklyUpdates/2017-06-19|June 19th, 2017]]
* [[WeeklyUpdates/2017-06-12|June 12th, 2017]]
* [[WeeklyUpdates/2017-06-05|June 5th, 2017]]
* May 29th, 2017 (No meeting due to US holiday for Memorial Day)
* [[WeeklyUpdates/2017-05-22|May 22nd, 2017]]
* [[WeeklyUpdates/2017-05-15|May 15th, 2017]]
* [[WeeklyUpdates/2017-05-08|May 8th, 2017]]
* [[WeeklyUpdates/2017-05-01|May 1st, 2017]]
* [[WeeklyUpdates/2017-04-24|April 24th, 2017]]
* [[WeeklyUpdates/2017-04-17|April 17th, 2017]]
* [[WeeklyUpdates/2017-04-10|April 10th, 2017]]
* [[WeeklyUpdates/2017-04-03|April 3rd, 2017]]
* [[WeeklyUpdates/2017-03-27|March 27th, 2017]]
* [[WeeklyUpdates/2017-03-20|March 20th, 2017]]
* [[WeeklyUpdates/2017-03-13|March 13th, 2017]]
* [[WeeklyUpdates/2017-03-06|March 6th, 2017]]
* [[WeeklyUpdates/2017-02-27|February 27th, 2017]]
* [[WeeklyUpdates/2017-02-13|February 13th, 2017]]
* [[WeeklyUpdates/2017-02-06|February 6th, 2017]]
* [[WeeklyUpdates/2017-01-30|January 30th, 2017]]
* [[WeeklyUpdates/2017-01-23|January 23rd, 2017]]
* January 16th, 2017 (no meeting due to US holiday)
* [[WeeklyUpdates/2017-01-09|January 9th, 2017]]
* January 2nd, 2017 (no meeting due to US New Year's Day holiday)
|}

{| class="wikitable collapsible collapsed" style="width: 100%"
! 2016
|-
|
* [[WeeklyUpdates/2016-12-26|December 26th, 2016]] (silent updates only. no meeting due to US Holiday observed)
* [[WeeklyUpdates/2016-12-19|December 19th, 2016]]
* [[WeeklyUpdates/2016-12-12|December 12th, 2016]]
* December 5th, 2016 (no meeting due to All-Hands travel)
* [[WeeklyUpdates/2016-11-28|November 28th, 2016]]
* [[WeeklyUpdates/2016-11-21|November 21st, 2016]]
* [[WeeklyUpdates/2016-11-21|November 21th, 2016]]
* [[WeeklyUpdates/2016-11-14|November 14th, 2016]]
* [[WeeklyUpdates/2016-11-07|November 7th, 2016]]
* [[WeeklyUpdates/2016-10-31|October 31st, 2016]]
* [[WeeklyUpdates/2016-10-24|October 24th, 2016]]
* [[WeeklyUpdates/2016-10-17|October 17th, 2016]]
* [[WeeklyUpdates/2016-10-10|October 10th, 2016]]
* [[WeeklyUpdates/2016-09-26|September 26th, 2016]]
* [[WeeklyUpdates/2016-09-19|September 19th, 2016]]
* [[WeeklyUpdates/2016-09-12|September 12th, 2016]]
* There was no meeting on September 5 because of the US Labor Day holiday.
* [[WeeklyUpdates/2016-08-29|August 29nd, 2016]]
* [[WeeklyUpdates/2016-08-22|August 22nd, 2016]]
* [[WeeklyUpdates/2016-08-15|August 15th, 2016]]
* [[WeeklyUpdates/2016-08-08|August 8th, 2016]]
* [[WeeklyUpdates/2016-08-01|August 1st, 2016]]
* [[WeeklyUpdates/2016-07-25|July 25th, 2016]]
* [[WeeklyUpdates/2016-07-18|July 18th, 2016]]
* [[WeeklyUpdates/2016-07-11|July 11th, 2016]]
* [[WeeklyUpdates/2016-06-27|June 27th, 2016]]
* [[WeeklyUpdates/2016-06-20|June 20th, 2016]]
* [[WeeklyUpdates/2016-06-06|June 6th, 2016]]
* [[WeeklyUpdates/2016-05-23|May 23rd, 2016]]
* [[WeeklyUpdates/2016-05-16|May 16th, 2016]]
* [[WeeklyUpdates/2016-05-09|May 9th, 2016]]
* [[WeeklyUpdates/2016-05-02|May 2nd, 2016]]
* [[WeeklyUpdates/2016-04-25|April 25th, 2016]]
* [[WeeklyUpdates/2016-04-18|April 18th, 2016]]
* [[WeeklyUpdates/2016-04-11|April 11th, 2016]]
* [[WeeklyUpdates/2016-04-04|April 4th, 2016]]
* [[WeeklyUpdates/2016-03-28|March 28th, 2016]]
* [[WeeklyUpdates/2016-03-21|March 21st, 2016]]
* [[WeeklyUpdates/2016-03-14|March 14th, 2016]]
* [[WeeklyUpdates/2016-03-07|March 7th, 2016]]
* [[WeeklyUpdates/2016-02-29|February 29th, 2016]]
* [[WeeklyUpdates/2016-02-22|February 22nd, 2016]]
* [[WeeklyUpdates/2016-02-15|February 15th, 2016]] (no live meeting due to [https://en.wikipedia.org/wiki/Washington's_Birthday Washington's Birthday] Holiday in the US.)
* [[WeeklyUpdates/2016-02-08|February 8th, 2016]]
* [[WeeklyUpdates/2016-02-01|February 1st, 2016]]
* [[WeeklyUpdates/2016-01-25|January 25th, 2016]]
* [[WeeklyUpdates/2016-01-11|January 11th, 2016]]
* [[WeeklyUpdates/2016-01-04|January 4th, 2016]]
|}

{| class="wikitable collapsible collapsed" style="width: 100%"
! 2015
|-
|
* [[WeeklyUpdates/2015-12-28|December 28th, 2015]] (no meeting, just announcements)
* December 21st (no meeting)
* [[WeeklyUpdates/2015-12-14|December 14th, 2015]] (no live meeting due to All Hands recovery)
* December 7th (no meeting due to All Hands)
* [[WeeklyUpdates/2015-11-30|November 30th, 2015]]
* [[WeeklyUpdates/2015-11-23|November 23rd, 2015]]
* [[WeeklyUpdates/2015-11-16|November 16th, 2015]]
* [[WeeklyUpdates/2015-11-09|November 9th, 2015]]
* [[WeeklyUpdates/2015-11-02|November 2nd, 2015]]
* [[WeeklyUpdates/2015-10-26|October 26th, 2015]]
* [[WeeklyUpdates/2015-10-19|October 19th, 2015]]
* [[WeeklyUpdates/2015-10-12|October 12th, 2015]]
* [[WeeklyUpdates/2015-10-05|October 5th, 2015]]
* [[WeeklyUpdates/2015-09-28|September 28th, 2015]]
* [[WeeklyUpdates/2015-09-21|September 21st, 2015]]
* [[WeeklyUpdates/2015-09-14|September 14th, 2015]]
* September 7th (No meeting due to Labor Day)
* [[WeeklyUpdates/2015-08-31|August 31st, 2015]]
* [[WeeklyUpdates/2015-08-24|August 24th, 2015]]
* [[WeeklyUpdates/2015-08-17|August 17th, 2015]]
* [[WeeklyUpdates/2015-08-10|August 10th, 2015]]
* [[WeeklyUpdates/2015-08-03|August 3rd, 2015]]
* [[WeeklyUpdates/2015-07-27|July 27th, 2015]]
* [[WeeklyUpdates/2015-07-20|July 20th, 2015]]
* [[WeeklyUpdates/2015-07-13|July 13th, 2015]]
* [[WeeklyUpdates/2015-07-06|July 6th, 2015]]
* [[WeeklyUpdates/2015-06-29|June 29th, 2015]]
* June 22nd, 2015 (no meeting due to All-Hands travel)
* [[WeeklyUpdates/2015-06-15|June 15th, 2015]]
* [[WeeklyUpdates/2015-06-08|June 8th, 2015]]
* [[WeeklyUpdates/2015-06-01|June 1st, 2015]]
* May 25th, 2015 (no meeting due to US Holiday)
* [[WeeklyUpdates/2015-05-18|May 18th, 2015]]
* [[WeeklyUpdates/2015-05-11|May 11th, 2015]]
* [[WeeklyUpdates/2015-05-04|May 4th, 2015]]
* [[WeeklyUpdates/2015-04-27|April 27th, 2015]]
* [[WeeklyUpdates/2015-04-20|April 20th, 2015]]
* [[WeeklyUpdates/2015-04-13|April 13th, 2015]]
* [[WeeklyUpdates/2015-04-06|April 6th, 2015]]
* [[WeeklyUpdates/2015-03-30|March 30th, 2015]]
* [[WeeklyUpdates/2015-03-23|March 23rd, 2015]]
* [[WeeklyUpdates/2015-03-16|March 16th, 2015]]
* [[WeeklyUpdates/2015-03-09|March 9th, 2015]]
* [[WeeklyUpdates/2015-03-02|March 2nd, 2015]]
* [[WeeklyUpdates/2015-02-23|February 23rd, 2015]]
* Feb 16th No meeting due to US Holiday
* [[WeeklyUpdates/2015-02-09|February 9nd, 2015]]
* [[WeeklyUpdates/2015-02-02|February 2nd, 2015]]
* [[WeeklyUpdates/2015-01-26|January 26th, 2015]]
* [[WeeklyUpdates/2015-01-19|January 19th, 2015]]
* [[WeeklyUpdates/2015-01-12|January 12th, 2015]]
* [[WeeklyUpdates/2015-01-05|January 5th, 2015]]
|}

{| class="wikitable collapsible collapsed" style="width: 100%"
! 2014
|-
|
*[[WeeklyUpdates/2014-12-29|December 29th, 2014]]
*[[WeeklyUpdates/2014-12-15|December 15th, 2014]]
*[[WeeklyUpdates/2014-12-08|December 8th, 2014]]
*[[WeeklyUpdates/2014-11-24|November 24th, 2014]]
*[[WeeklyUpdates/2014-11-17|November 17th, 2014]]
*[[WeeklyUpdates/2014-11-10|November 10th, 2014]]
*[[WeeklyUpdates/2014-11-03|November 3rd, 2014]]
*[[WeeklyUpdates/2014-10-27|October 27th, 2014]]
*[[WeeklyUpdates/2014-10-20|October 20th, 2014]]
*[[WeeklyUpdates/2014-10-13|October 13th, 2014]]
*[[WeeklyUpdates/2014-10-06|October 6th, 2014]]
*[[WeeklyUpdates/2014-09-29|September 29th, 2014]]
*[[WeeklyUpdates/2014-09-22|September 22th, 2014]]
*[[WeeklyUpdates/2014-09-15|September 15th, 2014]]
*[[WeeklyUpdates/2014-09-08|September 8th, 2014]]
*[[WeeklyUpdates/2014-09-01|September 1st, 2014]]
*[[WeeklyUpdates/2014-08-25|August 25, 2014]]
*[[WeeklyUpdates/2014-08-18|August 18, 2014]]
*[[WeeklyUpdates/2014-08-11|August 11, 2014]]
*[[WeeklyUpdates/2014-08-04|August 4, 2014]]
*[[WeeklyUpdates/2014-07-28|July 28, 2014]]
*[[WeeklyUpdates/2014-07-21|July 21, 2014]]
*[[WeeklyUpdates/2014-07-14|July 14, 2014]]
*[[WeeklyUpdates/2014-07-07|July 7, 2014]]
*[[WeeklyUpdates/2014-06-30|June 30, 2014]]
*[[WeeklyUpdates/2014-06-23|June 23, 2014]]
*[[WeeklyUpdates/2014-06-16|June 16, 2014]]
*[[WeeklyUpdates/2014-06-09|June 09, 2014]]
*[[WeeklyUpdates/2014-06-02|June 02, 2014]]
*[[WeeklyUpdates/2014-05-26|May 26, 2014]]
*[[WeeklyUpdates/2014-05-19|May 19, 2014]]
*[[WeeklyUpdates/2014-05-12|May 12, 2014]]
*[[WeeklyUpdates/2014-05-05|May 05, 2014]]
*[[WeeklyUpdates/2014-04-28|April 28, 2014]]
*[[WeeklyUpdates/2014-04-21|April 21, 2014]]
*[[WeeklyUpdates/2014-04-14|April 14, 2014]]
*[[WeeklyUpdates/2014-04-07|April 7, 2014]]
*[[WeeklyUpdates/2014-03-31|March 31, 2014]]
*[[WeeklyUpdates/2014-03-24|March 24, 2014]]
*[[WeeklyUpdates/2014-03-17|March 17, 2014]]
*[[WeeklyUpdates/2014-03-10|March 10, 2014]]
*[[WeeklyUpdates/2014-03-03|March 3, 2014]]
*[[WeeklyUpdates/2014-02-24|February 24, 2014]]
*[[WeeklyUpdates/2014-02-10|February 10, 2014]]
*[[WeeklyUpdates/2014-02-03|February 3, 2014]]
*[[WeeklyUpdates/2014-01-27|January 27, 2014]]
*[[WeeklyUpdates/2014-01-20|January 20, 2014]]
*[[WeeklyUpdates/2014-01-13|January 13, 2014]]
*[[WeeklyUpdates/2014-01-06|January 6, 2014]]
|}

{| class="wikitable collapsible collapsed" style="width: 100%"
! 2013
|-
|
*[[WeeklyUpdates/2013-12-16|December 16, 2013]]
*[[WeeklyUpdates/2013-12-09|December 9, 2013]]
*[[WeeklyUpdates/2013-12-02|December 2, 2013]]
*[[WeeklyUpdates/2013-11-25|November 25, 2013]]
*[[WeeklyUpdates/2013-11-18|November 18, 2013]]
*[[WeeklyUpdates/2013-11-11|November 11, 2013]]
*[[WeeklyUpdates/2013-11-04|November 4, 2013]]
*[[WeeklyUpdates/2013-10-28|October 28, 2013]]
*[[WeeklyUpdates/2013-10-21|October 21, 2013]]
*[[WeeklyUpdates/2013-10-14|October 14, 2013]]
*[[WeeklyUpdates/2013-10-07|October 7, 2013]]
*[[WeeklyUpdates/2013-09-30|September 30, 2013]]
*[[WeeklyUpdates/2013-09-23|September 23, 2013]]
*[[WeeklyUpdates/2013-09-16|September 16, 2013]]
*[[WeeklyUpdates/2013-09-09|September 9, 2013]]
*[[WeeklyUpdates/2013-09-02|September 2, 2013]]
*[[WeeklyUpdates/2013-08-26|August 26, 2013]]
*[[WeeklyUpdates/2013-08-19|August 19, 2013]]
*[[WeeklyUpdates/2013-08-12|August 12, 2013]]
*[[WeeklyUpdates/2013-08-05|August 5, 2013]]
*[[WeeklyUpdates/2013-07-29|July 29, 2013]]
*[[WeeklyUpdates/2013-07-22|July 22, 2013]]
*[[WeeklyUpdates/2013-07-15|July 15, 2013]]
*[[WeeklyUpdates/2013-07-08|July 8, 2013]]
*[[WeeklyUpdates/2013-07-01|July 1, 2013]]
*[[WeeklyUpdates/2013-06-24|June 24, 2013]]
*[[WeeklyUpdates/2013-06-17|June 17, 2013]]
*[[WeeklyUpdates/2013-06-10|June 10, 2013]]
*[[WeeklyUpdates/2013-06-03|June 3, 2013]]
*[[WeeklyUpdates/2013-05-20|May 20, 2013]]
*[[WeeklyUpdates/2013-05-13|May 13, 2013]]
*[[WeeklyUpdates/2013-05-06|May 6, 2013]]
*[[WeeklyUpdates/2013-04-29|April 29, 2013]]
*[[WeeklyUpdates/2013-04-22|April 22, 2013]]
*[[WeeklyUpdates/2013-04-15|April 15, 2013]]
*[[WeeklyUpdates/2013-04-08|April 8, 2013]]
*[[WeeklyUpdates/2013-04-01|April 1, 2013]]
*[[WeeklyUpdates/2013-03-25|March 25, 2013]]
*[[WeeklyUpdates/2013-03-18|March 18, 2013]]
*[[WeeklyUpdates/2013-03-11|March 11, 2013]]
*[[WeeklyUpdates/2013-03-04|March 4, 2013]]
*[[WeeklyUpdates/2013-02-25|February 25, 2013]]
*February 18, 2013 - ''No meeting.''
*[[WeeklyUpdates/2013-02-11|February 11, 2013]]
*[[WeeklyUpdates/2013-02-04|February 04, 2013]]
*[[WeeklyUpdates/2013-01-28|January 28, 2013]]
*[[WeeklyUpdates/2013-01-21|January 21, 2013]]
*[[WeeklyUpdates/2013-01-14|January 14, 2013]]
*[[WeeklyUpdates/2013-01-07|January 7, 2013]]
|}
{| class="wikitable collapsible collapsed" style="width: 100%"
! 2012
|-
|
*December 31, 2012 - ''No meeting.''
*December 24, 2012 - ''No meeting.''
*[[WeeklyUpdates/2012-12-17|December 17, 2012]]
*[[WeeklyUpdates/2012-12-10|December 10, 2012]]
*[[WeeklyUpdates/2012-12-03|December 03, 2012]]
*[[WeeklyUpdates/2012-11-26|November 26, 2012]]
*[[WeeklyUpdates/2012-11-19|November 19, 2012]]
*[[WeeklyUpdates/2012-11-12|November 12, 2012]]
*[[WeeklyUpdates/2012-11-05|November 5, 2012]]
*[[WeeklyUpdates/2012-10-29|October 29, 2012]]
*[[WeeklyUpdates/2012-10-22|October 22, 2012]]
*[[WeeklyUpdates/2012-10-15|October 15, 2012]]
*[[WeeklyUpdates/2012-10-08|October 8, 2012]]
*[[WeeklyUpdates/2012-10-01|October 1, 2012]]
*[[WeeklyUpdates/2012-09-24|September 24, 2012]]
*[[WeeklyUpdates/2012-09-17|September 17, 2012]]
*[[WeeklyUpdates/2012-09-10|September 10, 2012]]
*[[WeeklyUpdates/2012-08-27|August 27, 2012]]
*[[WeeklyUpdates/2012-08-20|August 20, 2012]]
*[[WeeklyUpdates/2012-08-13|August 13, 2012]]
*[[WeeklyUpdates/2012-08-06|August 06, 2012]]
*[[WeeklyUpdates/2012-07-30|July 30, 2012]]
*[[WeeklyUpdates/2012-07-23|July 23, 2012]]
*[[WeeklyUpdates/2012-07-16|July 16, 2012]]
*[[WeeklyUpdates/2012-07-09|July 9, 2012]]
*[[WeeklyUpdates/2012-07-02|July 2, 2012]]
*[[WeeklyUpdates/2012-06-25|June 25, 2012]]
*[[WeeklyUpdates/2012-06-18|June 18, 2012]]
*[[WeeklyUpdates/2012-06-11|June 11, 2012]]
*[[WeeklyUpdates/2012-06-04|June 4, 2012]]
*[[WeeklyUpdates/2012-05-28|May 28, 2012]]
*[[WeeklyUpdates/2012-05-21|May 21, 2012]]
*[[WeeklyUpdates/2012-05-14|May 14, 2012]]
*[[WeeklyUpdates/2012-05-07|May 7, 2012]]
*[[WeeklyUpdates/2012-04-30|April 30, 2012]]
*[[WeeklyUpdates/2012-04-23|April 23, 2012]]
*[[WeeklyUpdates/2012-04-16|April 16, 2012]]
*[[WeeklyUpdates/2012-04-09|April 9, 2012]]
*[[WeeklyUpdates/2012-04-02|April 2, 2012]]
*[[WeeklyUpdates/2012-03-26|March 26, 2012]]
*[[WeeklyUpdates/2012-03-19|March 19, 2012]]
*[[WeeklyUpdates/2012-03-12|March 12, 2012]]
*[[WeeklyUpdates/2012-03-05|March 5, 2012]]
*[[WeeklyUpdates/2012-02-27|February 27, 2012]]
*February 20, 2012 - ''No meeting.''
*[[WeeklyUpdates/2012-02-13|February 13, 2012]]
*[[WeeklyUpdates/2012-02-06|February 6, 2012]]
*[[WeeklyUpdates/2012-01-30|January 30, 2012]]
*[[WeeklyUpdates/2012-01-23|January 23, 2012]]
*January 16, 2012 - ''No meeting.''
*[[WeeklyUpdates/2012-01-09|January 9, 2012]]
*January 2, 2012 - ''No meeting.''
|}
{| class="wikitable collapsible collapsed" style="width: 100%"
! 2011
|-
|
*December 26, 2011 - ''No meeting.''
*[[WeeklyUpdates/2011-12-19|December 19, 2011]]
*[[WeeklyUpdates/2011-12-12|December 12, 2011]]
*[[WeeklyUpdates/2011-12-05|December 5, 2011]]
*[[WeeklyUpdates/2011-11-28|November 28, 2011]]
*[[WeeklyUpdates/2011-11-21|November 21, 2011]]
*[[WeeklyUpdates/2011-11-14|November 14, 2011]]
*[[WeeklyUpdates/2011-11-07|November 7, 2011]]
*[[WeeklyUpdates/2011-10-31|October 31, 2011]]
*[[WeeklyUpdates/2011-10-24|October 24, 2011]]
*[[WeeklyUpdates/2011-10-17|October 17, 2011]]
*[[WeeklyUpdates/2011-10-10|October 10, 2011]]
*[[WeeklyUpdates/2011-10-03|October 3, 2011]]
*[[WeeklyUpdates/2011-09-27|September 26, 2011]]
*[[WeeklyUpdates/2011-09-19|September 19, 2011]]
*September 12, 2011 - ''No meeting due to All-Hands week.''
*September 5, 2011 - ''No meeting due to US holiday.''
*[[WeeklyUpdates/2011-08-29|August 29, 2011]]
*[[WeeklyUpdates/2011-08-22|August 22, 2011]]
*[[WeeklyUpdates/2011-08-15|August 15, 2011]]
*[[WeeklyUpdates/2011-08-08|August 8, 2011]]
*[[WeeklyUpdates/2011-08-01|August 1, 2011]]
*[[WeeklyUpdates/2011-07-25|July 25, 2011]]
*[[WeeklyUpdates/2011-07-18|July 18, 2011]]
*[[WeeklyUpdates/2011-07-11|July 11, 2011]]
*July 4, 2011 - ''No meeting due to US holiday.''
*[[WeeklyUpdates/2011-06-27|June 27, 2011]]
*[[WeeklyUpdates/2011-06-20|June 20, 2011]]
*[[WeeklyUpdates/2011-06-13|June 13, 2011]]
*[[WeeklyUpdates/2011-06-06|June 6, 2011]]
*May 30, 2011 - ''No meeting due to US holiday.''
*[[WeeklyUpdates/2011-05-23|May 23, 2011]]
*[[WeeklyUpdates/2011-05-16|May 16, 2011]]
*[[WeeklyUpdates/2011-05-09|May 9, 2011]]
*[[WeeklyUpdates/2011-05-02|May 2, 2011]]
*[[WeeklyUpdates/2011-04-25|April 25, 2011]]
*[[WeeklyUpdates/2011-04-18|April 18, 2011]]
*[[WeeklyUpdates/2011-04-11|April 11, 2011]]
*April 4, 2011 - ''No meeting due to All-Hands week.''
*[[WeeklyUpdates/2011-03-28|March 28, 2011]]
*[[WeeklyUpdates/2011-03-21|March 21, 2011]]
*[[WeeklyUpdates/2011-03-14|March 14, 2011]]
*[[WeeklyUpdates/2011-03-07|March 7, 2011]]
*[[WeeklyUpdates/2011-02-28|February 28, 2011]]
*February 21, 2011 - ''No meeting due to US holiday.''
*[[WeeklyUpdates/2011-02-14|February 14, 2011]]
*[[WeeklyUpdates/2011-02-07|February 07, 2011]]
*[[WeeklyUpdates/2011-01-31|January 31, 2011]]
*[[WeeklyUpdates/2011-01-24|January 24, 2011]]
*January 17, 2011 - ''No meeting due to US holiday.''
*[[WeeklyUpdates/2011-01-10|January 10, 2011]]
*[[WeeklyUpdates/2011-01-03|January 3, 2011]]
|}

{| class="wikitable collapsible collapsed" style="width: 100%"
! 2010
|-
|
*December 27, 2010 - ''No meeting due to holiday season.''
*[[WeeklyUpdates/2010-12-20|December 20, 2010]]
*December 13, 2010 - ''No meeting due to Work Week''
*[[WeeklyUpdates/2010-12-06|December 6, 2010]]
*[[WeeklyUpdates/2010-11-29|November 29, 2010]]
*[[WeeklyUpdates/2010-11-22|November 22, 2010]]
*[[WeeklyUpdates/2010-11-15|November 15, 2010]]
*[[WeeklyUpdates/2010-11-08|November 08, 2010]]
*[[WeeklyUpdates/2010-11-01|November 01, 2010]]
*[[WeeklyUpdates/2010-10-25|October 25, 2010]]
*[[WeeklyUpdates/2010-10-18|October 18, 2010]]
*[[WeeklyUpdates/2010-10-11|October 11, 2010]]
*[[WeeklyUpdates/2010-10-04|October 4, 2010]]
*[[WeeklyUpdates/2010-09-27|September 27, 2010]]
*[[WeeklyUpdates/2010-09-20|September 20, 2010]]
*[[WeeklyUpdates/2010-09-13|September 13, 2010]]
*September 6, 2010 - ''No meeting due to US holiday''
*[[WeeklyUpdates/2010-08-30|August 30, 2010]]
*[[WeeklyUpdates/2010-08-23|August 23, 2010]]
*[[WeeklyUpdates/2010-08-16|August 16, 2010]]
*[[WeeklyUpdates/2010-08-09|August 9, 2010]]
*[[WeeklyUpdates/2010-08-02|August 2, 2010]]
*[[WeeklyUpdates/2010-07-26|July 26, 2010]]
*[[WeeklyUpdates/2010-07-19|July 19, 2010]]
*[[WeeklyUpdates/2010-07-12|July 12, 2010]]
*July 5, 2010 - ''No meeting due to summit''
*[[WeeklyUpdates/2010-06-28|June 28, 2010]]
*[[WeeklyUpdates/2010-06-21|June 21, 2010]]
*[[WeeklyUpdates/2010-06-14|June 14, 2010]]
*[[WeeklyUpdates/2010-06-07|June 7, 2010]]
*May 31, 2010 - ''No meeting due to US holiday''
*[[WeeklyUpdates/2010-05-24|May 24, 2010]]
*[[WeeklyUpdates/2010-05-17|May 17, 2010]]
*[[WeeklyUpdates/2010-05-10|May 10, 2010]]
*[[WeeklyUpdates/2010-05-03|May 03, 2010]]
*[[WeeklyUpdates/2010-04-26|April 26, 2010]]
*[[WeeklyUpdates/2010-04-19|April 19, 2010]]
*[[WeeklyUpdates/2010-04-12|April 12, 2010]]
*[[WeeklyUpdates/2010-04-05|April 5, 2010]]
*[[WeeklyUpdates/2010-03-29|March 29, 2010]]
*[[WeeklyUpdates/2010-03-22|March 22, 2010]]
*[[WeeklyUpdates/2010-03-15|March 15, 2010]]
*[[WeeklyUpdates/2010-03-08|March 8, 2010]]
*[[WeeklyUpdates/2010-03-01|March 1, 2010]]
*[[WeeklyUpdates/2010-02-22|February 22, 2010]]
*[[WeeklyUpdates/2010-02-15|February 15, 2010]]- No meeting due to holiday, please leave updates in the wiki.
*[[WeeklyUpdates/2010-02-08|February 8, 2010]]
*[[WeeklyUpdates/2010-02-01|February 1, 2010]]
*[[WeeklyUpdates/2010-01-25|January 25, 2010]]
*[[WeeklyUpdates/2010-01-18|January 18, 2010]]- No meeting due to US holiday, please leaves updates in the wiki.
*[[WeeklyUpdates/2010-01-11|January 11, 2010]]- First meeting using [[WeeklyUpdates/Guidance|new procedures]].
*[[WeeklyUpdates/2010-01-04|January 04, 2010]]
|}

{| class="wikitable collapsible collapsed" style="width: 100%"
! 2009
|-
|
*[[WeeklyUpdates/2009-12-28|December 28, 2009]]- No meeting due to holiday. Feel free to leave updates in the Wiki.
*[[WeeklyUpdates/2009-12-21|December 21, 2009]]
*[[WeeklyUpdates/2009-12-14|December 14, 2009]]
*[[WeeklyUpdates/2009-12-07|December 07, 2009]]- No meeting due to all day Mozilla Corp meetings. Feel free to leave updates in the Wiki.
*[[WeeklyUpdates/2009-11-30|November 30, 2009]]
*[[WeeklyUpdates/2009-11-23|November 23, 2009]]
*[[WeeklyUpdates/2009-11-16|November 16, 2009]]
*[[WeeklyUpdates/2009-11-09|November 09, 2009]]
*[[WeeklyUpdates/2009-11-02|November 02, 2009]] - Time Change! 19:00 UTC (11am PST)
*[[WeeklyUpdates/2009-10-26|October 26, 2009]]
*[[WeeklyUpdates/2009-10-19|October 19, 2009]]
*[[WeeklyUpdates/2009-10-12|October 12, 2009]]
*[[WeeklyUpdates/2009-10-05|October 05, 2009]]
*[[WeeklyUpdates/2009-09-28|September 28, 2009]]
*[[WeeklyUpdates/2009-09-21|September 21, 2009]]
*[[WeeklyUpdates/2009-09-14|September 14, 2009]]
*[[WeeklyUpdates/2009-09-07|September 07, 2009]] - No Meeting due to [http://en.wikipedia.org/wiki/Labor_Day Labor Day] Holiday
*[[WeeklyUpdates/2009-08-31|August 31, 2009]]
*[[WeeklyUpdates/2009-08-24|August 24, 2009]]
*[[WeeklyUpdates/2009-08-17|August 17, 2009]]
*[[WeeklyUpdates/2009-08-10|August 10, 2009]]
*[[WeeklyUpdates/2009-08-03|August 03, 2009]]
*[[WeeklyUpdates/2009-07-27|July 27, 2009]]
*[[WeeklyUpdates/2009-07-20|July 20, 2009]]
*[[WeeklyUpdates/2009-07-13|July 13, 2009]]
*[[WeeklyUpdates/2009-07-06|July 06, 2009]]
*[[WeeklyUpdates/2009-06-29|June 29, 2009]]
*[[WeeklyUpdates/2009-06-22|June 22, 2009]]
*[[WeeklyUpdates/2009-06-15|June 15, 2009]]
*[[WeeklyUpdates/2009-06-08|June 08, 2009]]
*[[WeeklyUpdates/2009-06-01|June 01, 2009]]
*[[WeeklyUpdates/2009-05-25|May 25, 2009]] - No meeting due to US Holiday: [http://en.wikipedia.org/wiki/Memorial_day Memorial Day]. Feel free to leave status!
*[[WeeklyUpdates/2009-05-18|May 18, 2009]]
*[[WeeklyUpdates/2009-05-11|May 11, 2009]]
*[[WeeklyUpdates/2009-05-04|May 04, 2009]]
*April 27, 2009 - no update meeting this week due to on-site event
*[[WeeklyUpdates/2009-04-20|April 20, 2009]]
*[[WeeklyUpdates/2009-04-13|April 13, 2009]]
*[[WeeklyUpdates/2009-04-06|April 06, 2009]]
*[[WeeklyUpdates/2009-03-30|March 30, 2009]]
*[[WeeklyUpdates/2009-03-23|March 23, 2009]]
*[[WeeklyUpdates/2009-03-16|March 16, 2009]]
*[[WeeklyUpdates/2009-03-09|March 09, 2009]]
*[[WeeklyUpdates/2009-03-02|March 02, 2009]]
*[[WeeklyUpdates/2009-02-23|February 23, 2009]]
*February 16, 2009 - No Meeting due to US Holiday
*[[WeeklyUpdates/2009-02-09|February 09, 2009]]
*[[WeeklyUpdates/2009-02-02|February 02, 2009]]
*[[WeeklyUpdates/2009-01-26|January 26, 2009]]
*January 19, 2009 - No Meeting due to US Holiday
*[[WeeklyUpdates/2009-01-12|January 12, 2009]]
*[[WeeklyUpdates/2009-01-05|January 05, 2009]]
|}

{| class="wikitable collapsible collapsed" style="width: 100%"
! 2008
|-
|
*[[WeeklyUpdates/2008-12-29|December 29, 2008]]
*[[WeeklyUpdates/2008-12-22|December 22, 2008]]
*[[WeeklyUpdates/2008-12-15|December 15, 2008]]
*[[WeeklyUpdates/2008-12-08|December 08, 2008]]
*[[WeeklyUpdates/2008-12-01|December 01, 2008]]
*[[WeeklyUpdates/2008-11-24|November 24, 2008]]
*[[WeeklyUpdates/2008-11-17|November 17, 2008]]
*[[WeeklyUpdates/2008-11-10|November 10, 2008]]
*[[WeeklyUpdates/2008-11-03|November 03, 2008]]
*[[WeeklyUpdates/2008-10-27|October 27, 2008]]
*[[WeeklyUpdates/2008-10-20|October 20, 2008]]
*[[WeeklyUpdates/2008-10-13|October 13, 2008]]
*[[WeeklyUpdates/2008-10-06|October 06, 2008]]
*[[WeeklyUpdates/2008-09-29|September 29, 2008]]
*[[WeeklyUpdates/2008-09-22|September 22, 2008]]
*[[WeeklyUpdates/2008-09-15|September 15, 2008]]
*[[WeeklyUpdates/2008-09-08|September 08, 2008]]
*September 01, 2008 - No Meeting due to US Holiday
*[[WeeklyUpdates/2008-08-25|August 25, 2008]]
*[[WeeklyUpdates/2008-08-18|August 18, 2008]]
*[[WeeklyUpdates/2008-08-11|August 11, 2008]]
*[[WeeklyUpdates/2008-08-04|August 04, 2008]]
*July 28, 2008 - No Meeting due to Summit
*[[WeeklyUpdates/2008-07-21|July 21, 2008]]
*[[WeeklyUpdates/2008-07-14|July 14, 2008]]
*[[WeeklyUpdates/2008-07-07|July 07, 2008]]
*[[WeeklyUpdates/2008-06-30|June 30, 2008]]
*[[WeeklyUpdates/2008-06-23|June 23, 2008]]
*[[WeeklyUpdates/2008-06-16|June 16, 2008]]
*[[WeeklyUpdates/2008-06-09|June 09, 2008]]
*[[WeeklyUpdates/2008-06-02|June 02, 2008]]
*May 26, 2008 - No Meeting due to US Holiday
*[[WeeklyUpdates/2008-05-19|May 19, 2008]]
*[[WeeklyUpdates/2008-05-12|May 12, 2008]]
*[[WeeklyUpdates/2008-05-05|May 05, 2008]]
*[[WeeklyUpdates/2008-04-28|April 28, 2008]]
*[[WeeklyUpdates/2008-04-21|April 21, 2008]]
*[[WeeklyUpdates/2008-04-14|April 14, 2008]]
*[[WeeklyUpdates/2008-04-07|April 07, 2008]]
*[[WeeklyUpdates/2008-03-31|March 31, 2008]]
*[[WeeklyUpdates/2008-03-24|March 24, 2008]]
*[[WeeklyUpdates/2008-03-17|March 17, 2008]]
*[[WeeklyUpdates/2008-03-10|March 10, 2008]]
*[[WeeklyUpdates/2008-03-03|March 03, 2008]]
*[[WeeklyUpdates/2008-02-25|February 25, 2008]]
*February 18, 2008 - No Meeting due to US Holiday
*[[WeeklyUpdates/2008-02-11|February 11, 2008]]
*[[WeeklyUpdates/2008-02-04|February 04, 2008]]
*[[WeeklyUpdates/2008-01-28|January 28, 2008]]
*January 21, 2008 - No Meeting due to US Holiday
*[[WeeklyUpdates/2008-01-14|January 14, 2008]]
*[[WeeklyUpdates/2008-01-07|January 07, 2008]]
|}

{| class="wikitable collapsible collapsed" style="width: 100%"
! 2007
|-
|
*December 31, 2007 - No Meeting due to US holiday season
*December 24, 2007 - No Meeting due to US holiday season
*[[WeeklyUpdates/2007-12-17|December 17, 2007]]
*[[WeeklyUpdates/2007-12-10|December 10, 2007]]
*[[WeeklyUpdates/2007-12-03|December 03, 2007]]
*[[WeeklyUpdates/2007-11-26|November 26, 2007]]
*[[WeeklyUpdates/2007-11-19|November 19, 2007]]
*November 12, 2007 - No Meeting due to US Holiday
*[[WeeklyUpdates/2007-11-05|November 05, 2007]]
*[[WeeklyUpdates/2007-10-29|October 29, 2007]]
*[[WeeklyUpdates/2007-10-22|October 22, 2007]]
*[[WeeklyUpdates/2007-10-15|October 15, 2007]]
*[[WeeklyUpdates/2007-10-08|October 08, 2007]]
*[[WeeklyUpdates/2007-10-01|October 01, 2007]]
*[[WeeklyUpdates/2007-09-24|September 24, 2007]]
*[[WeeklyUpdates/2007-09-17|September 17, 2007]]
*[[WeeklyUpdates/2007-09-10|September 10, 2007]]
*[[WeeklyUpdates/2007-08-27|August 27, 2007]]
*[[WeeklyUpdates/2007-08-20|August 20, 2007]]
*[[WeeklyUpdates/2007-08-13|August 13, 2007]]
*[[WeeklyUpdates/2007-08-06|August 6, 2007]]
*[[WeeklyUpdates/2007-07-30|July 30, 2007]]
*[[WeeklyUpdates/2007-07-23|July 23, 2007]]
*[[WeeklyUpdates/2007-07-16|July 16, 2007]]
*[[WeeklyUpdates/2007-07-09|July 9, 2007]]
*[[WeeklyUpdates/2007-07-02|July 2, 2007]]
*[[WeeklyUpdates/2007-06-25|June 25, 2007]]
*[[WeeklyUpdates/2007-06-18|June 18, 2007]]
*[[WeeklyUpdates/2007-06-11|June 11, 2007]]
*[[WeeklyUpdates/2007-06-04|June 4, 2007]]
*[[WeeklyUpdates/2007-05-21|May 21, 2007]]
*[[WeeklyUpdates/2007-05-14|May 14, 2007]]
*[[WeeklyUpdates/2007-05-07|May 7, 2007]]
*[[WeeklyUpdates/2007-04-30|April 30, 2007]]
*[[WeeklyUpdates/2007-04-23|April 23, 2007]]
*[[WeeklyUpdates/2007-04-16|April 16, 2007]]
*[[WeeklyUpdates/2007-04-09|April 9, 2007]]
*[[WeeklyUpdates/2007-04-02|April 2, 2007]]
*[[WeeklyUpdates/2007-03-26|March 26, 2007]]
*[[WeeklyUpdates/2007-03-19|March 19, 2007]]
*[[WeeklyUpdates/2007-03-12|March 12, 2007]]
*[[WeeklyUpdates/2007-03-05|March 5, 2007]]
*[[WeeklyUpdates/2007-02-26|February 26, 2007]]
*[[WeeklyUpdates/2007-02-12|February 12, 2007]]
*[[WeeklyUpdates/2007-02-05|February 5, 2007]]
*[[WeeklyUpdates/2007-01-29|January 29, 2007]]
*[[WeeklyUpdates/2007-01-22|January 22, 2007]]
*[[WeeklyUpdates/2007-01-08|January 08, 2007]]
|}

{| class="wikitable collapsible collapsed" style="width: 100%"
! 2006
|-
|
*[[WeeklyUpdates/2006-12-18|December 18, 2006]]
*[[WeeklyUpdates/2006-12-11|December 11, 2006]]
*[[WeeklyUpdates/2006-12-04|December 4, 2006]]
*[[WeeklyUpdates/2006-11-27|November 27, 2006]]
*[[WeeklyUpdates/2006-11-13|November 13, 2006]]
*[[WeeklyUpdates/2006-11-06|November 6, 2006]]
*[[WeeklyUpdates/2006-10-30|October 30, 2006]]
*[[WeeklyUpdates/2006-10-23|October 23, 2006]]
*[[WeeklyUpdates/2006-10-16|October 16, 2006]]
*[[WeeklyUpdates/2006-10-09|October 9, 2006]]
*[[WeeklyUpdates/2006-10-02|October 2, 2006]]
*[[WeeklyUpdates/2006-09-25|September 25, 2006]]
*[[WeeklyUpdates/2006-09-18|September 18, 2006]]
*[[WeeklyUpdates/2006-09-11|September 11, 2006]]
*September 4, 2006 - No Meeting due to US and Canadian Holiday
*[[WeeklyUpdates/2006-08-28|August 28, 2006]]
*[[WeeklyUpdates/2006-08-21|August 21, 2006]]
*[[WeeklyUpdates/2006-08-14|August 14, 2006]]
*[[WeeklyUpdates/2006-08-07|August 07, 2006]]
*[[WeeklyUpdates/2006-07-31|July 31, 2006]]
*[[WeeklyUpdates/2006-07-24|July 24, 2006]]
*[[WeeklyUpdates/2006-07-17|July 17, 2006]]
*[[WeeklyUpdates/2006-07-10|July 10, 2006]]
*July 3, 2006 - No Meeting due to US Holiday
*June 26, 2006 - No Meeting
*[[WeeklyUpdates/2006-06-19|June 19, 2006]]
*[[WeeklyUpdates/2006-06-12|June 12, 2006]]
*[[WeeklyUpdates/2006-06-05|June 05, 2006]]
*May 29, 2006 -- No Meeting due to US Holiday
*[[WeeklyUpdates/2006-05-22|May 22, 2006]]
*May 15, 2006 -- No Meeting due to XTech 2006 Conference
*[[WeeklyUpdates/2006-05-08|May 08, 2006]]
*[[WeeklyUpdates/2006-05-01|May 01, 2006]]
*[[WeeklyUpdates/2006-04-24|April 24, 2006]]
*[[WeeklyUpdates/2006-04-17|April 17, 2006]]
*[[WeeklyUpdates/2006-04-10|April 10, 2006]]
*[[WeeklyUpdates/2006-04-03|April 03, 2006]]
*[[WeeklyUpdates/2006-03-27|March 27, 2006]]
|}

''Note: Older [http://www-archive.mozilla.org/status/minutes.html meeting minutes] and [http://www-archive.mozilla.org/status/ status updates] are available on the www.mozilla.org archive site.''

[[Category:Weekly Updates]]
[[Category:Meeting Notes]]

WeeklyUpdates/2019-06-03

2019-05-31T20:21:19Z

Sfink: /* Welcome! */ added Krystal

{{WeeklyUpdateNav}}
* Every Monday @ 11:00am Pacific Time (19:00 UTC)
* Watch at https://mzl.la/project-meeting-2019-06-03 or anonymously at https://air.mozilla.org. You can also watch on the Mozilla YouTube channel at https://www.youtube.com/watch?v=uMa8nehFv40
* join #weekly-project-call on irc.mozilla.org or Slack for backchannel discussion
* If you plan on presenting, please join the Zoom video chat 20 minutes prior to the start of the meeting and announce to the A/V Technicians that you will be speaking so that they can confirm your Audio and Video.
* '''Presenters only:''' Zoom Meeting ID: 828 817 988 [https://mozilla.zoom.us/j/828817988 https://mozilla.zoom.us/j/828817988.] Do '''not''' use this room if you're not planning to speak.
* One-tap mobile
** +16465588656,,828817988# US (New York)
** +17207072699,,828817988# US
* Dial-in by your location
** +1 646 558 8656 US (New York)
** +1 720 707 2699 US
** 877 853 5257 US Toll-free
** +61 2 8015 2088 Australia
** +61 8 7150 1149 Australia
** 1800 893 423 Australia Toll-free
** +1 647 558 0588 Canada
** +33 1 8288 0188 France
** +33 7 5678 4048 France
** 0 805 082 588 France Toll-free
** +49 30 5679 5800 Germany
** +49 69 8088 3899 Germany
** +49 30 3080 6188 Germany
** 800 724 3138 Germany Toll-free
** +852 5808 6088 Hong Kong, China
** +44 203 695 0088 United Kingdom
** +44 203 966 3809 United Kingdom
** +44 203 051 2874 United Kingdom
** 0 800 031 5717 United Kingdom Toll-free

__TOC__

= Weekly Project Status Meeting Agenda =

Items in this section will be shared during the live status meeting.

== Friends of Mozilla [[Image:Tree.gif|Friends of Mozilla]] ==

== Upcoming Events ==

=== This Week ===

=== Monday, {{#time:d F|{{SUBPAGENAME}}}} ===

=== Tuesday, {{#time:d F|{{SUBPAGENAME}} +1 day}} ===

=== Wednesday, {{#time:d F|{{SUBPAGENAME}} +2 days}} ===

=== Thursday, {{#time:d F|{{SUBPAGENAME}} +3 days}} ===

=== Friday, {{#time:d F|{{SUBPAGENAME}} +4 days}} ===

=== Saturday, {{#time:d F|{{SUBPAGENAME}} +5 days}} ===

=== Sunday, {{#time:d F|{{SUBPAGENAME}} +6 days}} ===

=== Next Week ===

=== Later Events and Available Tickets ===

'''Mozilla DevRel Complimentary Tickets'''

Our DevRel Sponsorship team sometimes receives complimentary tickets to share with Mozillians interested in attending the following events. Please reach out to Sandra Persing at spersing@mozilla.com for more details.

''' Mozilla Sponsored Developer Events'''

Mozilla sponsored developer events around the globe:

== Speakers ==

The limit is '''3 minutes per topic'''. It's like a lightning talk, but don't feel that you have to have slides in order to make a presentation. If you plan on showing a video, you need to contact the Air Mozilla team before the day of the meeting or you will be deferred to the next week. The meeting is streamed in a 4:3 format in order to allow for split screen. If your slides are 16:9 "widescreen" format, please indicate in the "Sharing" column below.

{| class="fullwidth-table wikitable"
|-
! [https://mozillians.org/u/USERNAME Presenter]
! Title
! Topic
! Location
! Sharing
! Media
! More Details
|-
| Who Are You?
| What Do You Do?
| What are you going to talk about?
| Where are you presenting from? (Moz Space, your house, space)
| Will you be sharing your screen? (yes/no, 4:3 or 16:9)
| Links to slides or images you want displayed on screen
| Link to where audience can find out more information
|-
|}

= Welcome! =

Let's say hello to some new Mozillians! If you are not able to join the meeting live, you can add a link to a short video introducing yourself.

{| class="fullwidth-table wikitable"
|-
! ''Who is being introduced?''
! ''Who are you? (the introducer)''
! ''Where are you doing the introduction?''
! ''Where are they from?''
! ''How will they be part of Mozilla?''
|-

|-
| Their Name
| Your Name
| Intro location
| Their Location
| Their Role
|-
|-
| Jeane Carlos
| Punam Dahiya
| MTV
| MTV
| Intern - User Journey Engineering
|-
|-
| Alvina Waseem
| David Bolter
| Toronto
| Toronto
| Intern - GeckoView Engineering
|-
|-
| Krystal Yang
| Steve Fink
| MTV
| MTV
| Intern - SpiderMonkey GC
|-
|}

[[Category:Weekly Updates]]
[[Category:Meeting Notes]]

Mrgiggles

2019-03-29T23:31:09Z

Sfink: /* Areas of Functionality (aka Plugins) */ histoire, demangle

= Mr. Giggles =

mrgiggles is an IRC bot originally created for monitoring and reporting on the results of a static analysis for GC (garbage collection) rooting hazards. It has grown beyond this original purpose, as such things often do.

== Usage ==

For now, just ask him.

/msg mrgiggles help

== Areas of Functionality (aka Plugins) ==

* analysis: Reporting on static rooting hazard analysis results for SpiderMonkey engine (mrgiggles: help analysis)
* treewatch: Watching the tree for openings/closures (mrgiggles: tell me when inbound opens or mrgiggles: help treewatch)
* pun: Telling puns (mrgiggles: pun)
* map: Timezone lookup (mrgiggles: what time is it in Perth?)
* mqext: Suggest reviewers or bug components for patches to a given file (mrgiggles: who has reviewed nsJSEnvironment.cpp?)
* knowledge: Return information about the interpretation of hex values as nsresult codes, JS::Values, or poison patterns (mrgiggles: what is 0xe5e5e5e5e5f7?)
* histoire: keep a record of what you have been working on (confession: wrote patch for bug 5432100)
* demangle: demangle C++ symbols for *nix or Windows; no Rust yet, sorry (mrgiggles: demangle _ZZN2js3jit11X86Encoding6CCNameENS1_9ConditionEE5names)

== Source ==

The source code may be found at https://bitbucket.org/sfink/mrgiggles

Note that you will almost certainly want a mrgiggles_config.py file. (I'm not sure if it still works without one, but probably not.) Not so basic example:

<code>
config = {
'nick': 'drchuckles',
'server': "irc.mozilla.org",
'port': 6667,
'password': "...",
'bitly_token': 'e4718deadbeefdeadbeef2422078f51d2cc41a4c',
'poll-interval': 10, # Seconds
'debug-channel': '#my-debug-channel',
'report-channels': [ '#my-debug-channel', '#mychannel' ],
'nondebug-channels': [ '#mychannel', '#theirchannel' ],
'var-path': "/home/tweety/var/{nick}",

'plugins': {
'treewatch': { 'class': 'TreeWatchPlugin',
'poll-interval': 180 },
'mqext': { 'class': 'MQExtPlugin' },
'pulse': {
'class': 'PulsePlugin',
'server': 'pulse.mozilla.org',
'port': 5672,
'user': 'mrgiggles',
'password': '...',
'exchanges': {
'build': 'exchange/build',
},
'queues': {
'build': 'queue/{user}/builds',
},
},

'pun': { 'class': 'PunPlugin' },
}
}
</code>

Mrgiggles

2019-03-29T23:27:12Z

Sfink: /* Areas of Functionality (aka Plugins) */ knowledge example

= Mr. Giggles =

mrgiggles is an IRC bot originally created for monitoring and reporting on the results of a static analysis for GC (garbage collection) rooting hazards. It has grown beyond this original purpose, as such things often do.

== Usage ==

For now, just ask him.

/msg mrgiggles help

== Areas of Functionality (aka Plugins) ==

* analysis: Reporting on static rooting hazard analysis results for SpiderMonkey engine (mrgiggles: help analysis)
* treewatch: Watching the tree for openings/closures (mrgiggles: tell me when inbound opens or mrgiggles: help treewatch)
* pun: Telling puns (mrgiggles: pun)
* map: Timezone lookup (mrgiggles: what time is it in Perth?)
* mqext: Suggest reviewers or bug components for patches to a given file (mrgiggles: who has reviewed nsJSEnvironment.cpp?)
* knowledge: Return information about the interpretation of hex values as nsresult codes, JS::Values, or poison patterns (mrgiggles: what is 0xe5e5e5e5e5f7?)

== Source ==

The source code may be found at https://bitbucket.org/sfink/mrgiggles

Note that you will almost certainly want a mrgiggles_config.py file. (I'm not sure if it still works without one, but probably not.) Not so basic example:

<code>
config = {
'nick': 'drchuckles',
'server': "irc.mozilla.org",
'port': 6667,
'password': "...",
'bitly_token': 'e4718deadbeefdeadbeef2422078f51d2cc41a4c',
'poll-interval': 10, # Seconds
'debug-channel': '#my-debug-channel',
'report-channels': [ '#my-debug-channel', '#mychannel' ],
'nondebug-channels': [ '#mychannel', '#theirchannel' ],
'var-path': "/home/tweety/var/{nick}",

'plugins': {
'treewatch': { 'class': 'TreeWatchPlugin',
'poll-interval': 180 },
'mqext': { 'class': 'MQExtPlugin' },
'pulse': {
'class': 'PulsePlugin',
'server': 'pulse.mozilla.org',
'port': 5672,
'user': 'mrgiggles',
'password': '...',
'exchanges': {
'build': 'exchange/build',
},
'queues': {
'build': 'queue/{user}/builds',
},
},

'pun': { 'class': 'PunPlugin' },
}
}
</code>

Mrgiggles

2019-03-29T23:26:19Z

Sfink: /* Areas of Functionality (aka Plugins) */ knowledge plugin

= Mr. Giggles =

mrgiggles is an IRC bot originally created for monitoring and reporting on the results of a static analysis for GC (garbage collection) rooting hazards. It has grown beyond this original purpose, as such things often do.

== Usage ==

For now, just ask him.

/msg mrgiggles help

== Areas of Functionality (aka Plugins) ==

* analysis: Reporting on static rooting hazard analysis results for SpiderMonkey engine (mrgiggles: help analysis)
* treewatch: Watching the tree for openings/closures (mrgiggles: tell me when inbound opens or mrgiggles: help treewatch)
* pun: Telling puns (mrgiggles: pun)
* map: Timezone lookup (mrgiggles: what time is it in Perth?)
* mqext: Suggest reviewers or bug components for patches to a given file (mrgiggles: who has reviewed nsJSEnvironment.cpp?)
* knowledge: Return information about the interpretation of hex values as nsresult codes, JS::Values, or poison patterns

== Source ==

The source code may be found at https://bitbucket.org/sfink/mrgiggles

Note that you will almost certainly want a mrgiggles_config.py file. (I'm not sure if it still works without one, but probably not.) Not so basic example:

<code>
config = {
'nick': 'drchuckles',
'server': "irc.mozilla.org",
'port': 6667,
'password': "...",
'bitly_token': 'e4718deadbeefdeadbeef2422078f51d2cc41a4c',
'poll-interval': 10, # Seconds
'debug-channel': '#my-debug-channel',
'report-channels': [ '#my-debug-channel', '#mychannel' ],
'nondebug-channels': [ '#mychannel', '#theirchannel' ],
'var-path': "/home/tweety/var/{nick}",

'plugins': {
'treewatch': { 'class': 'TreeWatchPlugin',
'poll-interval': 180 },
'mqext': { 'class': 'MQExtPlugin' },
'pulse': {
'class': 'PulsePlugin',
'server': 'pulse.mozilla.org',
'port': 5672,
'user': 'mrgiggles',
'password': '...',
'exchanges': {
'build': 'exchange/build',
},
'queues': {
'build': 'queue/{user}/builds',
},
},

'pun': { 'class': 'PunPlugin' },
}
}
</code>

Sfink/Static Rooting Analysis

2019-01-14T20:59:25Z

Sfink: removed 90% of this doc; outdated. Did not update to current status.

If you want to implement a new analysis, then probably the easiest way is to skip all of the nasty hairy bits of compiling the tree with the plugin installed, and instead copy over some .xdb files from a try push (try: -b do -p linux64-haz --upload-xdbs) and just run the rest of it. Everything else is implemented with JS source files from js/src/devtools/rootAnalysis/. The xdb files are enormous uncompressed, but not too horrible compressed.

Javascript:Automation Builds

2018-05-18T16:38:27Z

Sfink: /* SM(tsan) */ make this a little scarier

= The Builds =

All of the '''SM(...)''' builds appearing on Treeherder are JS shell-only builds. Currently, they all
* Checkout the source
* Configure using a set of options appropriate to the specific build
* Build (by simply invoking make)
* Run tests, possibly differently depending on the specific build

All of this is done by running the shell script js/src/devtools/automation/autospider.sh <variant>, where <variant> is one of the filenames in js/src/devtools/automation/variants/.

= Reproducing a build =

You should be able to closely replicate a TH build by running autospider.sh yourself. For example, to replicate '''SM(cgc)''', you could be anywhere within your checkout, and run

<gecko-root>/js/src/devtools/automation/autospider.sh --clobber compacting

The default objdir is <gecko-root>/obj-spider. You can change it by setting the $OBJDIR environment variable.

To narrow the test down, delete some of the lines at the end of autospider.sh that run the various tests.

== Mapping variants to SM(...) names ==

There is no good way. They're hardcoded in the Treeherder code. Many of them even show up in multiple repos. Here's a snapshot:

* SM(cgc) - compacting
* SM(p) - plain or plaindebug
* SM(arm) - arm-sim or arm-sim-osx
* SM(arm64) - arm64-sim
* SM(exr) - exactrooting
* SM(r) - rootanalysis
* SM(pkg) - Standalone SpiderMonkey package.
* SM(tsan) - tsan

= Specific Build Information =

== SM(pkg) ==

The SM(pkg) builds create a tarball of all the sources used to make a standalone SpiderMonkey library and shell, untar it somewhere else, and then runs the autospider command listed above. To reproduce this packaging and unpackaging behavior, you can run this command:

<gecko-root>/testing/taskcluster/scripts/builder/build-sm-package.sh

== SM(tsan) ==

sm-tsan uses the clang ThreadSanitizer dynamic thread safety checker. Since this is a dynamic analysis, any given run may report only a subset of issues based on the exact timing of that run. One thing that means is that failures in this job may well be intermittent, and thus may not be due to the immediately preceding push. You may consider retriggering a failure a few times to see what to blame it on.

ThreadSanitizer failures are generally not security sensitive, though they can be. The usual rules apply -- eg if it's in GC code, it should be assumed to be sensitive until investigated.

Javascript:Automation Builds

2018-05-18T16:30:57Z

Sfink: /* SM(tsan) */ replace old tsan info

Javascript:Automation Builds

2017-05-20T01:17:18Z

Sfink: headers

= The Builds =

All of the '''SM(...)''' builds appearing on Treeherder are JS shell-only builds. Currently, they all
* Checkout the source
* Configure using a set of options appropriate to the specific build
* Build (by simply invoking make)
* Run tests, possibly differently depending on the specific build

All of this is done by running the shell script js/src/devtools/automation/autospider.sh <variant>, where <variant> is one of the filenames in js/src/devtools/automation/variants/.

= Reproducing a build =

You should be able to closely replicate a TH build by running autospider.sh yourself. For example, to replicate '''SM(cgc)''', you could be anywhere within your checkout, and run

<gecko-root>/js/src/devtools/automation/autospider.sh --clobber compacting

The default objdir is <gecko-root>/obj-spider. You can change it by setting the $OBJDIR environment variable.

To narrow the test down, delete some of the lines at the end of autospider.sh that run the various tests.

== Mapping variants to SM(...) names ==

There is no good way. They're hardcoded in the Treeherder code. Many of them even show up in multiple repos. Here's a snapshot:

* SM(cgc) - compacting
* SM(p) - plain or plaindebug
* SM(arm) - arm-sim or arm-sim-osx
* SM(arm64) - arm64-sim
* SM(exr) - exactrooting
* SM(r) - rootanalysis
* SM(pkg) - Standalone SpiderMonkey package.
* SM(tsan) - tsan

= Specific Build Information =

== SM(pkg) ==

The SM(pkg) builds create a tarball of all the sources used to make a standalone SpiderMonkey library and shell, untar it somewhere else, and then runs the autospider command listed above. To reproduce this packaging and unpackaging behavior, you can run this command:

<gecko-root>/testing/taskcluster/scripts/builder/build-sm-package.sh

== SM(tsan) ==

sm-tsan is a dynamic thread safety checker, which means that any given run will only report a subset of issues. Also, we have a number of errors currently in the codebase that it will allow through without turning the build red. These are listed in

<gecko-root>/js/src/devtools/automation/variants/tsan

under the 'expect-errors' key. These are a list of filename,function pairs. (We cannot use a line number because it would change whenever lines are added/removed.) For a given build, errors are summarized in a tsan_summary.txt artifact, and the detailed stack information produced by tsan will be bundled up in a tsan.tar.gz file containing per-pid outputs.

The mrgiggles server is running a script that downloads and categorizes the observed failures, but it isn't done yet (it misses some pushes), and it does not yet expose the information it collects. If you're looking into a specific failure, you can either dig it out of tsan.tar.gz, or ask sfink for the detailed failure information. (mrgiggles watches for job completions, downloads tsan.tar.gz, and records the failure stacks in a file named after the filename, line number, and function name.)

Javascript:Automation Builds

2017-05-20T01:13:16Z

Sfink: tsan info

= The Builds =

All of the '''SM(...)''' builds appearing on Treeherder are JS shell-only builds. Currently, they all
* Checkout the source
* Configure using a set of options appropriate to the specific build
* Build (by simply invoking make)
* Run tests, possibly differently depending on the specific build

All of this is done by running the shell script js/src/devtools/automation/autospider.sh <variant>, where <variant> is one of the filenames in js/src/devtools/automation/variants/.

= Reproducing a build =

You should be able to closely replicate a TH build by running autospider.sh yourself. For example, to replicate '''SM(cgc)''', you could be anywhere within your checkout, and run

<gecko-root>/js/src/devtools/automation/autospider.sh --clobber compacting

The default objdir is <gecko-root>/obj-spider. You can change it by setting the $OBJDIR environment variable.

To narrow the test down, delete some of the lines at the end of autospider.sh that run the various tests.

== Mapping variants to SM(...) names ==

There is no good way. They're hardcoded in the Treeherder code. Many of them even show up in multiple repos. Here's a snapshot:

* SM(cgc) - compacting
* SM(p) - plain or plaindebug
* SM(arm) - arm-sim or arm-sim-osx
* SM(arm64) - arm64-sim
* SM(exr) - exactrooting
* SM(r) - rootanalysis
* SM(pkg) - Standalone SpiderMonkey package.
* SM(tsan) - tsan

== Specific Builds ==

=== SM(pkg) ===

The SM(pkg) builds create a tarball of all the sources used to make a standalone SpiderMonkey library and shell, untar it somewhere else, and then runs the autospider command listed above. To reproduce this packaging and unpackaging behavior, you can run this command:

<gecko-root>/testing/taskcluster/scripts/builder/build-sm-package.sh

=== SM(tsan) ===

sm-tsan is a dynamic thread safety checker, which means that any given run will only report a subset of issues. Also, we have a number of errors currently in the codebase that it will allow through without turning the build red. These are listed in

<gecko-root>/js/src/devtools/automation/variants/tsan

under the 'expect-errors' key. These are a list of filename,function pairs. (We cannot use a line number because it would change whenever lines are added/removed.) For a given build, errors are summarized in a tsan_summary.txt artifact, and the detailed stack information produced by tsan will be bundled up in a tsan.tar.gz file containing per-pid outputs.

The mrgiggles server is running a script that downloads and categorizes the observed failures, but it isn't done yet (it misses some pushes), and it does not yet expose the information it collects. If you're looking into a specific failure, you can either dig it out of tsan.tar.gz, or ask sfink for the detailed failure information. (mrgiggles watches for job completions, downloads tsan.tar.gz, and records the failure stacks in a file named after the filename, line number, and function name.)

Javascript:Automation Builds

2017-05-20T01:00:33Z

Sfink: /* Mapping variants to SM(...) names */

Sfink/Moving GC

2017-05-06T16:47:47Z

Sfink: minor fixups

All garbage collection requires a way to find the set of objects that are
currently reachable. This requires knowing about all pointers into the JS heap
("roots"), as well as all pointers within the JS heap (the "heap graph"). GC
will do a graph traversal starting from the roots and visiting everything
reachable. This requires being able to find all roots during a GC.

A generational garbage collector (GGC) defines a subset of the JS heap as the
"nursery", and allocates most objects out of this nursery in the expectation
that many of them will die quickly (become unused and unreferenced). The
collector periodically sweeps through the nursery, packing only the live
objects into another area so that the nursery is empty and available for new
allocations again. It is important that this nursery sweep (a "minor
collection") only need to look at the *live* objects (plus some bookkeeping
information), NOT the full heap (or even a percentage of it) -- you want the
cost of minor collections to be proportional only to the amount of live data in
the nursery, and independent of the amount of garbage.

This requires two main capabilities: (1) the ability to move objects around,
and (2) a record of all external pointers into the nursery.

Incremental garbage collection (IGC) adds an additional requirement: at the
beginning of an incremental collection, all roots (external pointers) into the
heap are recorded, then the main program is allowed to continue running but is
interrupted periodically so the incremental collector can gradually trace the
whole heap graph. Because the graph can change during this sweep, any
intra-heap reference that is deleted must be marked (treated as live): such
references usually are either dead or reachable from somewhere else, but it's also possible that the main program
moved a reference from a part of the heap that has not yet been scanned to a
part that has already been scanned, and so it will not get marked during the
rest of the incremental collection. This adds a required capability (3): a
record of all pointers within the heap that were deleted while incremental GC
was active. Note that this is actually accomplished by putting them on the same mark stack as is used to record the current state of the incremental GC.

Capability #1 means that we need to be able to find and update all pointers
from outside the JS heap into the JS heap. (Intra-heap pointers can be found
and updated by scanning, so they don't need any special handling.) The embedding uses APIs to register certain data structures as part of the root set, as well as callbacks to record other root pointers during the GC. For pointers on the stack, we use the Stack Rooting API; see js/public/RootingAPI.h.

Capabilities #2 and #3 mean that we need "write barriers" for all JS heap
pointers stored within the C++ heap, which is a fancy way of saying that if you
modify a pointer into the heap, you may need to do something before and/or after
the write to update bookkeeping information. Capability #2 requires a
"post-barrier", an action taken after the write occurs (or at least, using the written value), to store a record of
any new pointer value that points (or might point) into the nursery. Capability #3
requires a "pre-barrier", an action taken before the write occurs, so it can
mark the overwritten value as live (before it is lost from the
graph).

---

You can divide memory into 4 partitions: the stack, the non-JS (C++) heap, the
JS nursery, and the JS tenured area. (Or you could say there's the stack and
the heap, and the heap is divided into JS and non-JS parts, and the JS part is
separated into a nursery and a tenured area, but it's the pointers between
these areas that matter so we'll keep them separate.)

Pointers from the stack to either part of the JS heap must be findable and
updatable during a moving GC. This is usually accomplished with Rooted<T>,
Handle<T>, and MutableHandle<T>, though aggregates of various sorts will also
use the Auto*Rooter classes as well. Pointers from the stack to either the
stack or the C++ heap don't matter.

Pointers from the C++ heap to the JS heap must be findable and updatable, and
writes must be barriered. Pointers from the C++ heap to the C++ heap don't matter to the GC. Pointers
from the C++ heap to the stack are kind of funky but don't matter to the GC.

Pointers from the tenured area to anywhere in the JS heap are automatically
findable and updatable, since you can scan the JS heap. Writes do need to be
barriered, in case they change to point to the nursery (for GGC) or move an
unscanned subgraph into the already-scanned region (for IGC). Pointers from
tenured to the stack (?!) or the C++ heap don't matter.

Pointers from the nursery are the same as those from tenured, except it doesn't
matter for GGC if a nursery pointer points to the nursery vs tenured. So the
post barrier is not needed. The pre barrier is not needed because incremental GC does a nursery collection before each slice.

Javascript:Hazard Builds

2017-04-12T22:52:56Z

Sfink: /* Diagnosing a rooting hazards failure */ added <code> tags

== Static Analysis for Rooting and Heap Write Hazards ==

Treeherder can run two static analysis builds: the full browser (linux64-haz), just the JS shell (linux64-shell-haz). They show up on treeherder as '''H''' and '''SM(H)'''.

=== Diagnosing a hazard failure ===

The first step is to look at what sort of hazard is being reported. There are two types that cause the job to fail: stack rooting hazards for garbage collection, and heap write thread safety hazards for stylo.

The summary output will include either the string "<N> rooting hazards detected" or "<N> heap write hazards detected out of <M> allowed". See the appropriate section below for each.

=== Diagnosing a rooting hazards failure ===

Click on the '''H''' build link, select the "Job details" pane on the bottom right, follow the "Inspect Task" link, and download the "<code>public/build/hazards.txt.gz</code>" file.

Example snippet:

<pre>
Function 'jsopcode.cpp:uint8 DecompileExpressionFromStack(JSContext*, int32, int32, class JS::Handle<JS::Value>, int8**)' has unrooted 'ed' of type 'ExpressionDecompiler' live across GC call 'uint8 ExpressionDecompiler::decompilePC(uint8*)' at js/src/jsopcode.cpp:1866
js/src/jsopcode.cpp:1866: Assume(74,75, !__temp_23*, true)
js/src/jsopcode.cpp:1867: Assign(75,76, return := 0)
js/src/jsopcode.cpp:1867: Call(76,77, ed.~ExpressionDecompiler())
GC Function: uint8 ExpressionDecompiler::decompilePC(uint8*)
JSString* js::ValueToSource(JSContext*, class JS::Handle<JS::Value>)
uint8 js::Invoke(JSContext*, JS::Value*, JS::Value*, uint32, JS::Value*, class JS::MutableHandle<JS::Value>)
uint8 js::Invoke(JSContext*, JS::CallArgs, uint32)
JSScript* JSFunction::getOrCreateScript(JSContext*)
uint8 JSFunction::createScriptForLazilyInterpretedFunction(JSContext*, class JS::Handle<JSFunction*>)
uint8 JSRuntime::cloneSelfHostedFunctionScript(JSContext*, class JS::Handle<js::PropertyName*>, class JS::Handle<JSFunction*>)
JSScript* js::CloneScript(JSContext*, class JS::Handle<JSObject*>, class JS::Handle<JSFunction*>, const class JS::Handle<JSScript*>, uint32)
JSObject* js::CloneStaticBlockObject(JSContext*, class JS::Handle<JSObject*>, class JS::Handle<js::StaticBlockObject*>)
js::StaticBlockObject* js::StaticBlockObject::create(js::ExclusiveContext*)
js::Shape* js::EmptyShape::getInitialShape(js::ExclusiveContext*, js::Class*, js::TaggedProto, JSObject*, JSObject*, uint32, uint32)
js::Shape* js::EmptyShape::getInitialShape(js::ExclusiveContext*, js::Class*, js::TaggedProto, JSObject*, JSObject*, uint64, uint32)
js::UnownedBaseShape* js::BaseShape::getUnowned(js::ExclusiveContext*, js::StackBaseShape*)
js::BaseShape* js_NewGCBaseShape(js::ThreadSafeContext*) [with js::AllowGC allowGC = (js::AllowGC)1u]
js::BaseShape* js::gc::NewGCThing(js::ThreadSafeContext*, uint32, uint64, uint32) [with T = js::BaseShape; js::AllowGC allowGC = (js::AllowGC)1u; size_t = long unsigned int]
void js::gc::RunDebugGC(JSContext*)
void js::MinorGC(JSRuntime*, uint32)
GC
</pre>

This means that a rooting hazard was discovered at <code>js/src/jsopcode.cpp</code> line 1866, in the function <code>DecompileExpressionFromStack</code> (it is prefixed with the filename because it's a static function.) The problem is that they're an unrooted variable '<code>ed</code>' that holds an <code>ExpressionDecompiler</code> live across a call to <code>decompilePC</code>. "Live" means that the variable is used after the call to <code>decompilePC</code> returns. <code>decompilePC</code> may trigger a GC according to the static call stack given starting from the line beginning with "GC Function:". The hazard itself has some barely comprehensible Assume(...) and Call(...) gibberish that describes the exact path of the variable into the function call. That stuff is rarely useful -- usually, you'll only need to look at it if it's complaining about a temporary and you want to know where the temporary came from. The type '<code>ExpressionDecompiler</code>' is believed to hold pointers to GC-controlled objects of some sort. The analysis currently does not describe the exact field it is worried about.

To unpack this a little, the analysis is saying the following can happen:

* <code>ExpressionDecompiler</code> contains some pointer to a GC thing. For example, it might have a field '<code>obj</code>' of type '<code>JSObject*</code>'.
* <code>DecompileExpressionFromStack</code> is called.
* A pointer is stored in that field of the '<code>ed</code>' variable.
* <code>decompilePC</code> is invoked, which calls <code>ValueToSource</code>, which calls <code>Invoke</code>, which eventually calls <code>js::MinorGC</code>
* during the resulting garbage collection, the object pointed to by <code>ed.obj</code> is moved to a different location. All pointers stored in the JS heap are updated automatically, as are all rooted pointers. <code>ed.obj</code> is not, because the GC doesn't know about it.
* after <code>decompilePC</code> returns, something accesses <code>ed.obj</code>. This is now a stale pointer, and may refer to just about anything -- the wrong object, an invalid object, or whatever. Badness 10000, as TeX would say.

=== Diagnosing a heap write hazard failure ===

For the thread unsafe heap write analysis, a hazard means that some Gecko_* function calls, directly or indirectly, code that writes to something on the heap, or calls an unknown function that *might* write to something on the heap. The analysis requires quite a few annotations to describe things that are actually safe. This section will be expanded as we gain more experience with the analysis, but here are some common issues:

* Adding a new Gecko_* function: often, you will need to annotate any outparams or owned (thread-local) parameters in the <code>treatAsSafeArgument</code> function in <code>js/src/devtools/rootAnalysis/analyzeHeapWrites.js</code>.
* Calling some libc function: if you add a call to some random libc function (eg sin() or floor() or ceil(), though the latter two are already annotated), the analysis will report an "External Function". Add it to <code>checkExternalFunction</code>, assuming it *doesn't* have the possibility of writing to shared heap memory.
* If you call some non-returning (crashing) function that the analysis doesn't know about, you'll need to add it to <code>ignoreContents</code>.

On the other hand, you might have a real thread safety issue on your hands. Shared caches are common problems. Fix it.

=== Analysis implementation ===

These builds are performed as follows:

* run the script testing/taskcluster/scripts/builder/build-haz-linux.sh, which sets up a build environment and runs the analysis within it, then uploads the resulting files
** compile an optimized JS shell to later run the analysis
** compile the browser with gcc, using a slightly modified version of the sixgill (http://svn.sixgill.org) gcc plugin, producing a set of .xdb files describing everything encountered during the compilation
** analyze the .xdb files with scripts in js/src/devtools/rootAnalysis

=== Running the analysis ===

==== Pushing to try ====

The easiest way to run an analysis is to push to try with the trychooser line |try: -b do -p linux64-haz| (or, if the hazards of interest are contained entirely within js/src, use |try: -b do -p linux64-shell-haz| for a much faster result). The expected turnaround time for linux64-haz is just under 2 hours.

The output will be uploaded and a link named "results" will be placed into the "job details" info pane on treeherder. If the analysis fails, you will see the number of failures. Navigate to the hazards.txt.gz file.

==== Running locally ====

To run the browser analysis, you must be on a Fedora/RedHat/CentOS linux64 machine. See js/src/devtools/rootAnalysis/README.md.

If you are running Debian or Ubuntu, then there is currently a problem running the full browser analysis. You can coerce the shell-only build to work by doing something like:

sudo apt-get install autoconf2.13 libnspr4 libnspr4-dev
sudo ln -s autoconf2.13 /usr/bin/autoconf-2.13
export CFLAGS="-B/usr/lib/x86_64-linux-gnu -I/usr/include/x86_64-linux-gnu"
export CXXFLAGS="-B/usr/lib/x86_64-linux-gnu -I/usr/include/x86_64-linux-gnu"

before running the script.

=== So you broke the analysis by adding a hazard. Now what? ===

Backout, fix the hazard, or (final resort) update the expected number of hazards in js/src/devtools/rootAnalysis/expect.browser.json (but don't do that).

The most common way to fix a hazard is to change the variable to be a Rooted type, as described in http://dxr.mozilla.org/mozilla-central/source/js/public/RootingAPI.h#l21

For more complicated cases, ask on #jsapi. If you don't get a response, ping sfink or jonco for rooting hazards, bholley or sfink for heap write hazards. Or if it's a deeper issue with the analysis logic, try bhackett (the author of both analyses.)

Javascript:Hazard Builds

2017-04-12T22:42:15Z

Sfink: /* Static Analysis for Rooting Hazards */ stuff about heap writes

== Static Analysis for Rooting and Heap Write Hazards ==

Treeherder can run two static analysis builds: the full browser (linux64-haz), just the JS shell (linux64-shell-haz). They show up on treeherder as '''H''' and '''SM(H)'''.

=== Diagnosing a hazard failure ===

The first step is to look at what sort of hazard is being reported. There are two types that cause the job to fail: stack rooting hazards for garbage collection, and heap write thread safety hazards for stylo.

The summary output will include either the string "<N> rooting hazards detected" or "<N> heap write hazards detected out of <M> allowed". See the appropriate section below for each.

=== Diagnosing a rooting hazards failure ===

Click on the '''H''' build link, select the "Job details" pane on the bottom right, follow the "Inspect Task" link, and download the "public/build/hazards.txt.gz" file.

Example snippet:

<pre>
Function 'jsopcode.cpp:uint8 DecompileExpressionFromStack(JSContext*, int32, int32, class JS::Handle<JS::Value>, int8**)' has unrooted 'ed' of type 'ExpressionDecompiler' live across GC call 'uint8 ExpressionDecompiler::decompilePC(uint8*)' at js/src/jsopcode.cpp:1866
js/src/jsopcode.cpp:1866: Assume(74,75, !__temp_23*, true)
js/src/jsopcode.cpp:1867: Assign(75,76, return := 0)
js/src/jsopcode.cpp:1867: Call(76,77, ed.~ExpressionDecompiler())
GC Function: uint8 ExpressionDecompiler::decompilePC(uint8*)
JSString* js::ValueToSource(JSContext*, class JS::Handle<JS::Value>)
uint8 js::Invoke(JSContext*, JS::Value*, JS::Value*, uint32, JS::Value*, class JS::MutableHandle<JS::Value>)
uint8 js::Invoke(JSContext*, JS::CallArgs, uint32)
JSScript* JSFunction::getOrCreateScript(JSContext*)
uint8 JSFunction::createScriptForLazilyInterpretedFunction(JSContext*, class JS::Handle<JSFunction*>)
uint8 JSRuntime::cloneSelfHostedFunctionScript(JSContext*, class JS::Handle<js::PropertyName*>, class JS::Handle<JSFunction*>)
JSScript* js::CloneScript(JSContext*, class JS::Handle<JSObject*>, class JS::Handle<JSFunction*>, const class JS::Handle<JSScript*>, uint32)
JSObject* js::CloneStaticBlockObject(JSContext*, class JS::Handle<JSObject*>, class JS::Handle<js::StaticBlockObject*>)
js::StaticBlockObject* js::StaticBlockObject::create(js::ExclusiveContext*)
js::Shape* js::EmptyShape::getInitialShape(js::ExclusiveContext*, js::Class*, js::TaggedProto, JSObject*, JSObject*, uint32, uint32)
js::Shape* js::EmptyShape::getInitialShape(js::ExclusiveContext*, js::Class*, js::TaggedProto, JSObject*, JSObject*, uint64, uint32)
js::UnownedBaseShape* js::BaseShape::getUnowned(js::ExclusiveContext*, js::StackBaseShape*)
js::BaseShape* js_NewGCBaseShape(js::ThreadSafeContext*) [with js::AllowGC allowGC = (js::AllowGC)1u]
js::BaseShape* js::gc::NewGCThing(js::ThreadSafeContext*, uint32, uint64, uint32) [with T = js::BaseShape; js::AllowGC allowGC = (js::AllowGC)1u; size_t = long unsigned int]
void js::gc::RunDebugGC(JSContext*)
void js::MinorGC(JSRuntime*, uint32)
GC
</pre>

This means that a rooting hazard was discovered at js/src/jsopcode.cpp line 1866, in the function DecompileExpressionFromStack (it is prefixed with the filename because it's a static function.) The problem is that they're an unrooted variable 'ed' that holds an ExpressionDecompiler live across a call to decompilePC. "Live" means that the variable is used after the call to decompilePC returns. decompilePC may trigger a GC according to the static call stack given starting from the line beginning with "GC Function:". The hazard itself has some barely comprehensible Assume(...) and Call(...) gibberish that describes the exact path of the variable into the function call. That stuff is rarely useful -- usually, you'll only need to look at it if it's complaining about a temporary and you want to know where the temporary came from. The type 'ExpressionDecompiler' is believed to hold pointers to GC-controlled objects of some sort. The analysis currently does not describe the exact field it is worried about.

To unpack this a little, the analysis is saying the following can happen:

* ExpressionDecompiler contains some pointer to a GC thing. For example, it might have a field 'obj' of type 'JSObject*'.
* DecompileExpressionFromStack is called.
* A pointer is stored in that field of the 'ed' variable.
* decompilePC is invoked, which calls ValueToSource, which calls Invoke, which eventually calls js::MinorGC
* during the resulting garbage collection, the object pointed to by ed.obj is moved to a different location. All pointers stored in the JS heap are updated automatically, as are all rooted pointers. ed.obj is not, because the GC doesn't know about it.
* after decompilePC returns, something accesses ed.obj. This is now a stale pointer, and may refer to just about anything -- the wrong object, an invalid object, or whatever. Badness 10000, as TeX would say.

=== Diagnosing a heap write hazard failure ===

For the thread unsafe heap write analysis, a hazard means that some Gecko_* function calls, directly or indirectly, code that writes to something on the heap, or calls an unknown function that *might* write to something on the heap. The analysis requires quite a few annotations to describe things that are actually safe. This section will be expanded as we gain more experience with the analysis, but here are some common issues:

* Adding a new Gecko_* function: often, you will need to annotate any outparams or owned (thread-local) parameters in the <code>treatAsSafeArgument</code> function in <code>js/src/devtools/rootAnalysis/analyzeHeapWrites.js</code>.
* Calling some libc function: if you add a call to some random libc function (eg sin() or floor() or ceil(), though the latter two are already annotated), the analysis will report an "External Function". Add it to <code>checkExternalFunction</code>, assuming it *doesn't* have the possibility of writing to shared heap memory.
* If you call some non-returning (crashing) function that the analysis doesn't know about, you'll need to add it to <code>ignoreContents</code>.

On the other hand, you might have a real thread safety issue on your hands. Shared caches are common problems. Fix it.

=== Analysis implementation ===

These builds are performed as follows:

* run the script testing/taskcluster/scripts/builder/build-haz-linux.sh, which sets up a build environment and runs the analysis within it, then uploads the resulting files
** compile an optimized JS shell to later run the analysis
** compile the browser with gcc, using a slightly modified version of the sixgill (http://svn.sixgill.org) gcc plugin, producing a set of .xdb files describing everything encountered during the compilation
** analyze the .xdb files with scripts in js/src/devtools/rootAnalysis

=== Running the analysis ===

==== Pushing to try ====

The easiest way to run an analysis is to push to try with the trychooser line |try: -b do -p linux64-haz| (or, if the hazards of interest are contained entirely within js/src, use |try: -b do -p linux64-shell-haz| for a much faster result). The expected turnaround time for linux64-haz is just under 2 hours.

The output will be uploaded and a link named "results" will be placed into the "job details" info pane on treeherder. If the analysis fails, you will see the number of failures. Navigate to the hazards.txt.gz file.

==== Running locally ====

To run the browser analysis, you must be on a Fedora/RedHat/CentOS linux64 machine. See js/src/devtools/rootAnalysis/README.md.

If you are running Debian or Ubuntu, then there is currently a problem running the full browser analysis. You can coerce the shell-only build to work by doing something like:

sudo apt-get install autoconf2.13 libnspr4 libnspr4-dev
sudo ln -s autoconf2.13 /usr/bin/autoconf-2.13
export CFLAGS="-B/usr/lib/x86_64-linux-gnu -I/usr/include/x86_64-linux-gnu"
export CXXFLAGS="-B/usr/lib/x86_64-linux-gnu -I/usr/include/x86_64-linux-gnu"

before running the script.

=== So you broke the analysis by adding a hazard. Now what? ===

Backout, fix the hazard, or (final resort) update the expected number of hazards in js/src/devtools/rootAnalysis/expect.browser.json (but don't do that).

The most common way to fix a hazard is to change the variable to be a Rooted type, as described in http://dxr.mozilla.org/mozilla-central/source/js/public/RootingAPI.h#l21

For more complicated cases, ask on #jsapi. If you don't get a response, ping sfink or jonco for rooting hazards, bholley or sfink for heap write hazards. Or if it's a deeper issue with the analysis logic, try bhackett (the author of both analyses.)

Javascript:Hazard Builds

2016-12-29T22:29:28Z

Sfink: terrence gone.

== Static Analysis for Rooting Hazards ==

Treeherder can run two static analysis builds: the full browser (linux64-haz), just the JS shell (linux64-shell-haz). They show up on treeherder as '''H''' and '''SM(H)'''.

=== Diagnosing a hazard failure ===

Click on the '''H''' build link, select the "Job details" pane on the bottom right, follow the "Inspect Task" link, and download the "public/build/hazards.txt.gz" file.

Example snippet:

<pre>
Function 'jsopcode.cpp:uint8 DecompileExpressionFromStack(JSContext*, int32, int32, class JS::Handle<JS::Value>, int8**)' has unrooted 'ed' of type 'ExpressionDecompiler' live across GC call 'uint8 ExpressionDecompiler::decompilePC(uint8*)' at js/src/jsopcode.cpp:1866
js/src/jsopcode.cpp:1866: Assume(74,75, !__temp_23*, true)
js/src/jsopcode.cpp:1867: Assign(75,76, return := 0)
js/src/jsopcode.cpp:1867: Call(76,77, ed.~ExpressionDecompiler())
GC Function: uint8 ExpressionDecompiler::decompilePC(uint8*)
JSString* js::ValueToSource(JSContext*, class JS::Handle<JS::Value>)
uint8 js::Invoke(JSContext*, JS::Value*, JS::Value*, uint32, JS::Value*, class JS::MutableHandle<JS::Value>)
uint8 js::Invoke(JSContext*, JS::CallArgs, uint32)
JSScript* JSFunction::getOrCreateScript(JSContext*)
uint8 JSFunction::createScriptForLazilyInterpretedFunction(JSContext*, class JS::Handle<JSFunction*>)
uint8 JSRuntime::cloneSelfHostedFunctionScript(JSContext*, class JS::Handle<js::PropertyName*>, class JS::Handle<JSFunction*>)
JSScript* js::CloneScript(JSContext*, class JS::Handle<JSObject*>, class JS::Handle<JSFunction*>, const class JS::Handle<JSScript*>, uint32)
JSObject* js::CloneStaticBlockObject(JSContext*, class JS::Handle<JSObject*>, class JS::Handle<js::StaticBlockObject*>)
js::StaticBlockObject* js::StaticBlockObject::create(js::ExclusiveContext*)
js::Shape* js::EmptyShape::getInitialShape(js::ExclusiveContext*, js::Class*, js::TaggedProto, JSObject*, JSObject*, uint32, uint32)
js::Shape* js::EmptyShape::getInitialShape(js::ExclusiveContext*, js::Class*, js::TaggedProto, JSObject*, JSObject*, uint64, uint32)
js::UnownedBaseShape* js::BaseShape::getUnowned(js::ExclusiveContext*, js::StackBaseShape*)
js::BaseShape* js_NewGCBaseShape(js::ThreadSafeContext*) [with js::AllowGC allowGC = (js::AllowGC)1u]
js::BaseShape* js::gc::NewGCThing(js::ThreadSafeContext*, uint32, uint64, uint32) [with T = js::BaseShape; js::AllowGC allowGC = (js::AllowGC)1u; size_t = long unsigned int]
void js::gc::RunDebugGC(JSContext*)
void js::MinorGC(JSRuntime*, uint32)
GC
</pre>

This means that a rooting hazard was discovered at js/src/jsopcode.cpp line 1866, in the function DecompileExpressionFromStack (it is prefixed with the filename because it's a static function.) The problem is that they're an unrooted variable 'ed' that holds an ExpressionDecompiler live across a call to decompilePC. "Live" means that the variable is used after the call to decompilePC returns. decompilePC may trigger a GC according to the static call stack given starting from the line beginning with "GC Function:". The hazard itself has some barely comprehensible Assume(...) and Call(...) gibberish that describes the exact path of the variable into the function call. That stuff is rarely useful -- usually, you'll only need to look at it if it's complaining about a temporary and you want to know where the temporary came from. The type 'ExpressionDecompiler' is believed to hold pointers to GC-controlled objects of some sort. The analysis currently does not describe the exact field it is worried about.

To unpack this a little, the analysis is saying the following can happen:

* ExpressionDecompiler contains some pointer to a GC thing. For example, it might have a field 'obj' of type 'JSObject*'.
* DecompileExpressionFromStack is called.
* A pointer is stored in that field of the 'ed' variable.
* decompilePC is invoked, which calls ValueToSource, which calls Invoke, which eventually calls js::MinorGC
* during the resulting garbage collection, the object pointed to by ed.obj is moved to a different location. All pointers stored in the JS heap are updated automatically, as are all rooted pointers. ed.obj is not, because the GC doesn't know about it.
* after decompilePC returns, something accesses ed.obj. This is now a stale pointer, and may refer to just about anything -- the wrong object, an invalid object, or whatever. Badness 10000, as TeX would say.

=== Analysis implementation ===

These builds are performed as follows:

* run the script testing/taskcluster/scripts/builder/build-haz-linux.sh, which sets up a build environment and runs the analysis within it, then uploads the resulting files
** compile an optimized JS shell to later run the analysis
** compile the browser with gcc, using a slightly modified version of the sixgill (http://svn.sixgill.org) gcc plugin, producing a set of .xdb files describing everything encountered during the compilation
** analyze the .xdb files with scripts in js/src/devtools/rootAnalysis

=== Running the analysis ===

==== Pushing to try ====

The easiest way to run an analysis is to push to try with the trychooser line |try: -b do -p linux64-haz| (or, if the hazards of interest are contained entirely within js/src, use |try: -b do -p linux64-shell-haz| for a much faster result). The expected turnaround time for linux64-haz is just under 2 hours.

The output will be uploaded and a link named "results" will be placed into the "job details" info pane on treeherder. If the analysis fails, you will see the number of failures. Navigate to the hazards.txt.gz file.

==== Running locally ====

To run the browser analysis, you must be on a Fedora/RedHat/CentOS linux64 machine. See js/src/devtools/rootAnalysis/README.md.

If you are running Debian or Ubuntu, then there is currently a problem running the full browser analysis. You can coerce the shell-only build to work by doing something like:

sudo apt-get install autoconf2.13 libnspr4 libnspr4-dev
sudo ln -s autoconf2.13 /usr/bin/autoconf-2.13
export CFLAGS="-B/usr/lib/x86_64-linux-gnu -I/usr/include/x86_64-linux-gnu"
export CXXFLAGS="-B/usr/lib/x86_64-linux-gnu -I/usr/include/x86_64-linux-gnu"

before running the script.

=== So you broke the analysis by adding a hazard. Now what? ===

Backout, fix the hazard, or (final resort) update the expected number of hazards in js/src/devtools/rootAnalysis/expect.browser.json (but don't do that).

The most common way to fix a hazard is to change the variable to be a Rooted type, as described in http://dxr.mozilla.org/mozilla-central/source/js/public/RootingAPI.h#l21

For more complicated cases, ask on #jsapi. If you don't get a response, ping sfink or jonco.

JavaScript:New to SpiderMonkey

2016-10-11T16:20:01Z

Sfink: /* Try server */ tbpl -> th

== Tutorial: your first patch ==

The first step to getting involved with SpiderMonkey is to make your first patch. This guides you through it, and at the end you should have learnt a lot of the procedures and formalisms involved in getting things done here.

We'll assume you're on a Unix-y platform, and that you know what you're doing. We'll ignore nearly all details.

=== Get the code ===

Spidermonkey development happens in the "mozilla-central" mercurial repository:

hg clone http://hg.mozilla.org/mozilla-central spidermonkey

=== Build the js shell ===

Most of the time, you'll be working with the Javascript shell, instead of the full Firefox browser. So build the shell:

cd spidermonkey/js/src
cp configure.in configure && chmod +x configure # or autoconf2.13 or autoconf-2.13
mkdir build_DBG.OBJ
cd build_DBG.OBJ
../configure --enable-debug --disable-optimize
make # or make -j8
cd ..

If you're having trouble or are missing dependencies, refer to [https://developer.mozilla.org/en/SpiderMonkey/Build_Documentation#Building_SpiderMonkey_tip Building SpiderMonkey Tip].

=== Fix something ===

At this point, you're ready to make your first fix.

TODO: something useless. Maybe adding a datemicrosecond function.

==== Building your changes ====

Having made the change, build the shell again.

make -C build_DBG.OBJ

==== Testing your changes ====

It builds. Hurray. Time to run the tests to check you haven't broken anything.

jit-test/jit_test.py build_DBG.OBJ/dist/bin/js
(The location of the shell has changed, it used to be build_DBG.OBJ/js)

The jit-tests are pretty quick, and should give you an idea if you've gotten something wrong. Assuming nothing goes wrong, try the ref-tests:

tests/jstests.py build_DBG.OBJ/dist/bin/js

Note that some of these tests fail depending on the timezone and locale they're run in, so if you get any errors that don't seem related to your changes, re-run the tests with a shell build without your changes applied and compare the results.

==== Benchmark your changes ====

Tests all pass. Congrats, you didn't break anything. Now, did you make it faster or slower? We benchmark using the v8 and SunSpider benchmarks. Get the benchmarks:

svn checkout http://svn.webkit.org/repository/webkit/trunk/PerformanceTests/SunSpider

And now run them:

cd SunSpider
./sunspider --shell=../build_DBG.OBJ/dist/bin/js --run=30 --suite=sunspider-0.9.1
cd ..

===== Optimized build =====

Whoops, we benchmarked the debug version. Let's make an optimized build to test instead.

mkdir build_OPT.OBJ
cd build_OPT.OBJ
../configure --disable-debug --enable-optimize
make
cd ..

Repeat the sunspider steps above, and take note of the line that looks like:

Results are located at sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js

You'll need that later.

===== Baseline version / Mercurial Queues =====

We need to time our optimized version against the baseline version. This calls for a brief introduction to mercurial queues, which used to be the way most people managed their SpiderMonkey workflow (though these days many people use native hg, native hg + evolution, or git):

hg qinit
hg qnew my_first_patch -f
hg qrefresh

This puts your current work into a patch, managed by Mercurial, symbolically called my_first_patch. To pop the patch off:

hg qpop

And we're back to our pristine version.

===== Compare =====

Build again and rerun SunSpider again. You should now have two files like:

sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js

Compare them using the compare script:

cd SunSpider
./sunspider-compare-results --shell=../build_DBG.OBJ/js --suite=sunspider-0.9.1 FILE1-withoutPatch FILE2-withPatch

=== Get a real bug ===

At this point, you've seen nearly everything you need to do hack on SpiderMonkey. So it's time to get a real bug to work on. You can get a bug on [http://www.joshmatthews.net/bugsahoy/?jseng=1&unowned=1 Bugs Ahoy].

Fix the bug, updating the bug report with your progress, and asking questions as you go (either in the bug comments, or in [irc://irc.mozilla.org/#jsapi #jsapi]). When it's done, repeat all the steps above. Then it's time to get your patch into the tree.

=== Submit a patch ===

To get the patch from mercurial, use:

hg qdiff # if you're using queues or
hg diff # if you're not

Add it to the bug as an attachment.

=== Get a review ===

Nothing gets into the tree without a review, so you'll need one. The [[JavaScript:Hackers|SpiderMonkey hackers list]] is a good place to start: if your patch changes something listed as an area of expertise for someone there, that's a good person to ask for a review.

Alternatively run <code>hg blame</code> on the files you've changed, and check who has been changing related code recently. They're likely to be good candidates. An irc bot can automate this process for a single file if you enter "/msg mrgiggles who can review something.cpp?" into your irc client.

The review will consist of comments on your changes, suggesting or requesting alternative ways to do something and asking you to make changes where needed. They might also request additional changes, for example tests. Fix what they ask, resubmit the patch to bugzilla, and ask for another review. After you repeat this step a few times, they will mark the patch as "<code>r+</code>" meaning it's now good to commit.

=== Commit ===

You can't commit to mozilla-central / mozilla-inbound until you have "level 3" access, so you'll need someone to do this for you. Try asking in [irc://irc.mozilla.org/#jsapi #jsapi], or add the <code>checkin-needed</code> keyword to the bug. After you have been contributing for a while, you can get level 3 access by [https://www.mozilla.org/hacking/commit-access-policy/ applying for it].

After committing, a large series of tests will be run to make sure you didn't break anything. You will need to hang around to make sure you didn't break something. It is difficult to determine what failures are real and what are what we call "intermittent oranges" ("orange" because that is the color used on our continuous integration dashboard for test failures). If you do break something, a sheriff will probably let you know via IRC and will probably back your patch out. You can always ask [irc://irc.mozilla.org/#jsapi for help] determining what is going on. (Over time you'll get a feel for figuring out when breakage is real on your own.)

== Overview of the JS engine ==

The JS engine is a swiftly moving target. The most detailed information is available at https://developer.mozilla.org/en/SpiderMonkey. Here are some particularly interesting, mostly up-to-date resources:

=== High level overviews ===

(Outdated) http://hacks.mozilla.org/2010/03/a-quick-note-on-javascript-engine-components/

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals

=== Medium level documentation ===

jsapi.h: http://hg.mozilla.org/mozilla-central/file/tip/js/src/jsapi.h and the files in http://hg.mozilla.org/mozilla-central/file/tip/js/public

Frequently used coding recipes and mappings from JS idioms to SpiderMonkey code: https://developer.mozilla.org/En/SpiderMonkey/JSAPI_Cookbook

=== Detailed documentation ===

Build: https://developer.mozilla.org/en/SpiderMonkey/Build_Documentation

Testing: https://developer.mozilla.org/en/SpiderMonkey/Running_Automated_JavaScript_Tests

Shell: https://developer.mozilla.org/En/SpiderMonkey/Introduction_to_the_JavaScript_shell

Function reference: https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference

== Collaboration and teamwork ==

=== Communication (in descending order of information content) ===

Nearly all communication is handled through [https://bugzilla.mozilla.org Bugzilla]. All bugs, feature requests, issues, enhancements, etc, are all referred to as bugs. No code may enter the Mozilla repository without being a patch attached to a bugzilla bug first. To follow all SpiderMonkey related bugs:

Go to [https://bugzilla.mozilla.org/userprefs.cgi?tab=email email preferences]
Watch the user general@spidermonkey.bugs
Or watch one of the JS components in the Core product: JavaScript Engine, JavaScript Engine: JIT, JavaScript: GC, or JavaScript: Standard Library

SpiderMonkey contributors generally hang out in the very active [irc://irc.mozilla.org/jsapi #jsapi IRC channel].

The [https://www.mozilla.org/about/forums/#dev-tech-js-engine-internals js-internals mailing list] is used for communicating with other SpiderMonkey hackers. (Internals as in discussing the internals of the SpiderMonkey engine. All are welcome on the list.).

Reading Planet Mozilla is the best way to keep up with the Mozilla project, which includes some SpiderMonkey related blogs:

[https://blog.mozilla.org/javascript General JavaScript blog]
[http://blog.mozilla.com/jorendorff Jason Orendorff]
[http://blog.mozilla.com/nnethercote/ Nicholas Nethercote]
[http://whereswalden.com/ Jeff Walden]
[https://itcouldbesomuchbetter.wordpress.com Jim Blandy]
[https://jandemooij.nl/ Jan de Mooij]
[https://h4writer.com/ Hannes Verschore]
[http://rfrn.org/~shu/ Shu-yu Guo]
[https://blog.benj.me/tag/mozilla.html Benjamin Bouvier]

The [https://developer.mozilla.org/en/SpiderMonkey#Community js-engine mailing list] is generally used for communicating with people who embed SpiderMonkey, such as asking questions and announcing API changes. No actual development happens on the list.

== Code considerations ==

=== Repository ===

Most active work on SpiderMonkey is done in the [http://hg.mozilla.org/mozilla-central mozilla-central] branch of the mozilla repository.

=== Coding Style ===

For many years, SpiderMonkey was written in C, and is gradually moving to C++. We still avoid many features such as run-time type information and exceptions, and generally avoid virtual functions for core data, but have come around to the glory of templates and namespaces relatively recently. Read the [[JavaScript:SpiderMonkey:C++ Coding Style|Coding Style]]. Do NOT read the portability guidelines, which I will not link to, since they are very out of date.

=== Workflow ===

Everything goes through bugzilla. We find a bug or have an idea, then submit it to bugzilla, then file patches to solve it. When it is solved, the patch is reviewed by team members, and is then committed to the [http://hg.mozilla.org/integration/mozilla-inbound mozilla-inbound repository]. A link to the commit is then automatically added as a comment to the bug. mozilla-inbound is periodically merged to mozilla-central by a Sheriff. This exempts us from watching [https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound treeherder] to check for failures caused by our patches, and commits are automatically backed out if errors are found.

==== Sample Workflows ====

(Outdated) [http://blog.mozilla.com/nnethercote/2009/07/27/how-i-work-on-tracemonkey/ Nicholas Nethercote: How I work on Tracemonkey]

=== Policy ===

The following docs are for the Mozilla project, and differ ever so slightly from what you should do for SpiderMonkey. For example, you should find reviewers in #jsapi rather than #developers.

[http://www.mozilla.org/hacking/committer/ How to get commit access]

[https://developer.mozilla.org/en/Creating_a_patch How to make patches]

[https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch Submitting a patch]

[https://developer.mozilla.org/en/Supported_build_configurations Supported Platforms]

==== .hgrc file ====

This .hgrc file contains a lot of the wisdom distilled through the wiki:

[extensions]
mq =

[ui]
username = First Last <email@domain.tld>

[alias]
qfulldiff = diff --rev qparent:.

[defaults]
diff = -p -U 8
qdiff = -p -U 8
qnew = -U
commit = -v

[diff]
git = true
showfunc = true
unified = 8

[paths]
try = ssh://email@domain.tld@hg.mozilla.org/try/

=== Try server ===

Often, you may be a little wary of breaking things. Mozilla has a [[Build:TryServer|Try Server]] where you can send a patch, and it'll be built and tested on tons of machines, which report to [https://treeherder.mozilla.org/#/jobs?repo=try TreeHerder]. Although you don't have [https://www.mozilla.org/hacking/commit-access-policy/ access] to TryServer just yet, you can get someone else to push it there for you. Just attach a patch to your bug, and ask in a comment, or on [irc://irc.mozilla.org/#jsapi #jsapi]. To be able to push to try-server yourself, you will need "level 1" access, which you can [https://www.mozilla.org/hacking/commit-access-policy/ request] once you've contributed a patch or two.

=== Mercurial Queues ===

Since most of our lives revolve around patches, and we use Mercurial, nearly everybody uses Mercurial queues.

Queues are based on the idea of patch management. Each queue consists of a series of patches, applied sequentially. The aim of the game is to split potential commits into simple, bite-sized chunks which are easy to review. This also makes it simple to experiment without polluting your existing work on a bug, to spin parts off into new bugs, and to rapidly apply and unapply patches (as demonstrated in the tutorial above).

==== Enabling ====

Add the following snippet to your .hgrc file to enable MQ

[extensions]
mq =

==== Example MQ workflow ====

Clone the repository to deal with a bug:

hg clone http://hg.mozilla.org/mozilla-central

Initialize your queue:

hg qinit -c

Create a new patch, with some name:

hg qnew first_attempt

Work on the patch, try to fix the bug, test, compile, etc.

Refresh (save your work into the patch):

hg qrefresh

Repeat a few times.

Rename the patch (because your first name wasn't appliable):

hg qrename refactor_the_whatsit

Create a new patch to try a logically separate part of the same bug:

hg qnew rip_out_the_old_thing

Repeat the process a few times, until you have solved the problem. During this time, it can often be useful to go back and forth between patches:

hg qpop # unapply a patch
hg qpush # reapply a patch
hg qpop -a # unapply all patches
hg qpush -a # reapply all patches

Combine all the patches into a single patch, which you submit to bugzilla:

hg qpush -a
hg qdiff --rev qparent:. > my_wonderful_patch.patch

Commit the patches to your local patch repository, in case you make a mistake (You might do this periodically):

hg qcommit -m "Some message. Doesn't have to be good, this won't be committed to the repository, it's just for you"

Go back to the old patches and fiddle with them based on feedback:

hg qpop
hg qrefresh
etc

There are some more complex techniques that we won't go into in detail. You can enable only some patches using qguard and qselect, and you can reorder the patches by manually editing the .hg/patches/series file. But be careful!

[[Category:New Contributor Landing Page]]

JavaScript:New to SpiderMonkey

2016-10-11T16:19:15Z

Sfink: /* Workflow */ treeherder, inbound

== Tutorial: your first patch ==

The first step to getting involved with SpiderMonkey is to make your first patch. This guides you through it, and at the end you should have learnt a lot of the procedures and formalisms involved in getting things done here.

We'll assume you're on a Unix-y platform, and that you know what you're doing. We'll ignore nearly all details.

=== Get the code ===

Spidermonkey development happens in the "mozilla-central" mercurial repository:

hg clone http://hg.mozilla.org/mozilla-central spidermonkey

=== Build the js shell ===

Most of the time, you'll be working with the Javascript shell, instead of the full Firefox browser. So build the shell:

cd spidermonkey/js/src
cp configure.in configure && chmod +x configure # or autoconf2.13 or autoconf-2.13
mkdir build_DBG.OBJ
cd build_DBG.OBJ
../configure --enable-debug --disable-optimize
make # or make -j8
cd ..

If you're having trouble or are missing dependencies, refer to [https://developer.mozilla.org/en/SpiderMonkey/Build_Documentation#Building_SpiderMonkey_tip Building SpiderMonkey Tip].

=== Fix something ===

At this point, you're ready to make your first fix.

TODO: something useless. Maybe adding a datemicrosecond function.

==== Building your changes ====

Having made the change, build the shell again.

make -C build_DBG.OBJ

==== Testing your changes ====

It builds. Hurray. Time to run the tests to check you haven't broken anything.

jit-test/jit_test.py build_DBG.OBJ/dist/bin/js
(The location of the shell has changed, it used to be build_DBG.OBJ/js)

The jit-tests are pretty quick, and should give you an idea if you've gotten something wrong. Assuming nothing goes wrong, try the ref-tests:

tests/jstests.py build_DBG.OBJ/dist/bin/js

Note that some of these tests fail depending on the timezone and locale they're run in, so if you get any errors that don't seem related to your changes, re-run the tests with a shell build without your changes applied and compare the results.

==== Benchmark your changes ====

Tests all pass. Congrats, you didn't break anything. Now, did you make it faster or slower? We benchmark using the v8 and SunSpider benchmarks. Get the benchmarks:

svn checkout http://svn.webkit.org/repository/webkit/trunk/PerformanceTests/SunSpider

And now run them:

cd SunSpider
./sunspider --shell=../build_DBG.OBJ/dist/bin/js --run=30 --suite=sunspider-0.9.1
cd ..

===== Optimized build =====

Whoops, we benchmarked the debug version. Let's make an optimized build to test instead.

mkdir build_OPT.OBJ
cd build_OPT.OBJ
../configure --disable-debug --enable-optimize
make
cd ..

Repeat the sunspider steps above, and take note of the line that looks like:

Results are located at sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js

You'll need that later.

===== Baseline version / Mercurial Queues =====

We need to time our optimized version against the baseline version. This calls for a brief introduction to mercurial queues, which used to be the way most people managed their SpiderMonkey workflow (though these days many people use native hg, native hg + evolution, or git):

hg qinit
hg qnew my_first_patch -f
hg qrefresh

This puts your current work into a patch, managed by Mercurial, symbolically called my_first_patch. To pop the patch off:

hg qpop

And we're back to our pristine version.

===== Compare =====

Build again and rerun SunSpider again. You should now have two files like:

sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js

Compare them using the compare script:

cd SunSpider
./sunspider-compare-results --shell=../build_DBG.OBJ/js --suite=sunspider-0.9.1 FILE1-withoutPatch FILE2-withPatch

=== Get a real bug ===

At this point, you've seen nearly everything you need to do hack on SpiderMonkey. So it's time to get a real bug to work on. You can get a bug on [http://www.joshmatthews.net/bugsahoy/?jseng=1&unowned=1 Bugs Ahoy].

Fix the bug, updating the bug report with your progress, and asking questions as you go (either in the bug comments, or in [irc://irc.mozilla.org/#jsapi #jsapi]). When it's done, repeat all the steps above. Then it's time to get your patch into the tree.

=== Submit a patch ===

To get the patch from mercurial, use:

hg qdiff # if you're using queues or
hg diff # if you're not

Add it to the bug as an attachment.

=== Get a review ===

Nothing gets into the tree without a review, so you'll need one. The [[JavaScript:Hackers|SpiderMonkey hackers list]] is a good place to start: if your patch changes something listed as an area of expertise for someone there, that's a good person to ask for a review.

Alternatively run <code>hg blame</code> on the files you've changed, and check who has been changing related code recently. They're likely to be good candidates. An irc bot can automate this process for a single file if you enter "/msg mrgiggles who can review something.cpp?" into your irc client.

The review will consist of comments on your changes, suggesting or requesting alternative ways to do something and asking you to make changes where needed. They might also request additional changes, for example tests. Fix what they ask, resubmit the patch to bugzilla, and ask for another review. After you repeat this step a few times, they will mark the patch as "<code>r+</code>" meaning it's now good to commit.

=== Commit ===

You can't commit to mozilla-central / mozilla-inbound until you have "level 3" access, so you'll need someone to do this for you. Try asking in [irc://irc.mozilla.org/#jsapi #jsapi], or add the <code>checkin-needed</code> keyword to the bug. After you have been contributing for a while, you can get level 3 access by [https://www.mozilla.org/hacking/commit-access-policy/ applying for it].

After committing, a large series of tests will be run to make sure you didn't break anything. You will need to hang around to make sure you didn't break something. It is difficult to determine what failures are real and what are what we call "intermittent oranges" ("orange" because that is the color used on our continuous integration dashboard for test failures). If you do break something, a sheriff will probably let you know via IRC and will probably back your patch out. You can always ask [irc://irc.mozilla.org/#jsapi for help] determining what is going on. (Over time you'll get a feel for figuring out when breakage is real on your own.)

== Overview of the JS engine ==

The JS engine is a swiftly moving target. The most detailed information is available at https://developer.mozilla.org/en/SpiderMonkey. Here are some particularly interesting, mostly up-to-date resources:

=== High level overviews ===

(Outdated) http://hacks.mozilla.org/2010/03/a-quick-note-on-javascript-engine-components/

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals

=== Medium level documentation ===

jsapi.h: http://hg.mozilla.org/mozilla-central/file/tip/js/src/jsapi.h and the files in http://hg.mozilla.org/mozilla-central/file/tip/js/public

Frequently used coding recipes and mappings from JS idioms to SpiderMonkey code: https://developer.mozilla.org/En/SpiderMonkey/JSAPI_Cookbook

=== Detailed documentation ===

Build: https://developer.mozilla.org/en/SpiderMonkey/Build_Documentation

Testing: https://developer.mozilla.org/en/SpiderMonkey/Running_Automated_JavaScript_Tests

Shell: https://developer.mozilla.org/En/SpiderMonkey/Introduction_to_the_JavaScript_shell

Function reference: https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference

== Collaboration and teamwork ==

=== Communication (in descending order of information content) ===

Nearly all communication is handled through [https://bugzilla.mozilla.org Bugzilla]. All bugs, feature requests, issues, enhancements, etc, are all referred to as bugs. No code may enter the Mozilla repository without being a patch attached to a bugzilla bug first. To follow all SpiderMonkey related bugs:

Go to [https://bugzilla.mozilla.org/userprefs.cgi?tab=email email preferences]
Watch the user general@spidermonkey.bugs
Or watch one of the JS components in the Core product: JavaScript Engine, JavaScript Engine: JIT, JavaScript: GC, or JavaScript: Standard Library

SpiderMonkey contributors generally hang out in the very active [irc://irc.mozilla.org/jsapi #jsapi IRC channel].

The [https://www.mozilla.org/about/forums/#dev-tech-js-engine-internals js-internals mailing list] is used for communicating with other SpiderMonkey hackers. (Internals as in discussing the internals of the SpiderMonkey engine. All are welcome on the list.).

Reading Planet Mozilla is the best way to keep up with the Mozilla project, which includes some SpiderMonkey related blogs:

[https://blog.mozilla.org/javascript General JavaScript blog]
[http://blog.mozilla.com/jorendorff Jason Orendorff]
[http://blog.mozilla.com/nnethercote/ Nicholas Nethercote]
[http://whereswalden.com/ Jeff Walden]
[https://itcouldbesomuchbetter.wordpress.com Jim Blandy]
[https://jandemooij.nl/ Jan de Mooij]
[https://h4writer.com/ Hannes Verschore]
[http://rfrn.org/~shu/ Shu-yu Guo]
[https://blog.benj.me/tag/mozilla.html Benjamin Bouvier]

The [https://developer.mozilla.org/en/SpiderMonkey#Community js-engine mailing list] is generally used for communicating with people who embed SpiderMonkey, such as asking questions and announcing API changes. No actual development happens on the list.

== Code considerations ==

=== Repository ===

Most active work on SpiderMonkey is done in the [http://hg.mozilla.org/mozilla-central mozilla-central] branch of the mozilla repository.

=== Coding Style ===

For many years, SpiderMonkey was written in C, and is gradually moving to C++. We still avoid many features such as run-time type information and exceptions, and generally avoid virtual functions for core data, but have come around to the glory of templates and namespaces relatively recently. Read the [[JavaScript:SpiderMonkey:C++ Coding Style|Coding Style]]. Do NOT read the portability guidelines, which I will not link to, since they are very out of date.

=== Workflow ===

Everything goes through bugzilla. We find a bug or have an idea, then submit it to bugzilla, then file patches to solve it. When it is solved, the patch is reviewed by team members, and is then committed to the [http://hg.mozilla.org/integration/mozilla-inbound mozilla-inbound repository]. A link to the commit is then automatically added as a comment to the bug. mozilla-inbound is periodically merged to mozilla-central by a Sheriff. This exempts us from watching [https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound treeherder] to check for failures caused by our patches, and commits are automatically backed out if errors are found.

==== Sample Workflows ====

(Outdated) [http://blog.mozilla.com/nnethercote/2009/07/27/how-i-work-on-tracemonkey/ Nicholas Nethercote: How I work on Tracemonkey]

=== Policy ===

The following docs are for the Mozilla project, and differ ever so slightly from what you should do for SpiderMonkey. For example, you should find reviewers in #jsapi rather than #developers.

[http://www.mozilla.org/hacking/committer/ How to get commit access]

[https://developer.mozilla.org/en/Creating_a_patch How to make patches]

[https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch Submitting a patch]

[https://developer.mozilla.org/en/Supported_build_configurations Supported Platforms]

==== .hgrc file ====

This .hgrc file contains a lot of the wisdom distilled through the wiki:

[extensions]
mq =

[ui]
username = First Last <email@domain.tld>

[alias]
qfulldiff = diff --rev qparent:.

[defaults]
diff = -p -U 8
qdiff = -p -U 8
qnew = -U
commit = -v

[diff]
git = true
showfunc = true
unified = 8

[paths]
try = ssh://email@domain.tld@hg.mozilla.org/try/

=== Try server ===

Often, you may be a little wary of breaking things. Mozilla has a [[Build:TryServer|Try Server]] where you can send a patch, and it'll be built and tested on tons of machines, which report to [http://tbpl.mozilla.org/?tree=Try TBPL]. Although you don't have [https://www.mozilla.org/hacking/commit-access-policy/ access] to TryServer just yet, you can get someone else to push it there for you. Just attach a patch to your bug, and ask in a comment, or on [irc://irc.mozilla.org/#jsapi #jsapi]. To be able to push to try-server yourself, you will need "level 1" access, which you can [https://www.mozilla.org/hacking/commit-access-policy/ request] once you've contributed a patch or two.

=== Mercurial Queues ===

Since most of our lives revolve around patches, and we use Mercurial, nearly everybody uses Mercurial queues.

Queues are based on the idea of patch management. Each queue consists of a series of patches, applied sequentially. The aim of the game is to split potential commits into simple, bite-sized chunks which are easy to review. This also makes it simple to experiment without polluting your existing work on a bug, to spin parts off into new bugs, and to rapidly apply and unapply patches (as demonstrated in the tutorial above).

==== Enabling ====

Add the following snippet to your .hgrc file to enable MQ

[extensions]
mq =

==== Example MQ workflow ====

Clone the repository to deal with a bug:

hg clone http://hg.mozilla.org/mozilla-central

Initialize your queue:

hg qinit -c

Create a new patch, with some name:

hg qnew first_attempt

Work on the patch, try to fix the bug, test, compile, etc.

Refresh (save your work into the patch):

hg qrefresh

Repeat a few times.

Rename the patch (because your first name wasn't appliable):

hg qrename refactor_the_whatsit

Create a new patch to try a logically separate part of the same bug:

hg qnew rip_out_the_old_thing

Repeat the process a few times, until you have solved the problem. During this time, it can often be useful to go back and forth between patches:

hg qpop # unapply a patch
hg qpush # reapply a patch
hg qpop -a # unapply all patches
hg qpush -a # reapply all patches

Combine all the patches into a single patch, which you submit to bugzilla:

hg qpush -a
hg qdiff --rev qparent:. > my_wonderful_patch.patch

Commit the patches to your local patch repository, in case you make a mistake (You might do this periodically):

hg qcommit -m "Some message. Doesn't have to be good, this won't be committed to the repository, it's just for you"

Go back to the old patches and fiddle with them based on feedback:

hg qpop
hg qrefresh
etc

There are some more complex techniques that we won't go into in detail. You can enable only some patches using qguard and qselect, and you can reorder the patches by manually editing the .hg/patches/series file. But be careful!

[[Category:New Contributor Landing Page]]

JavaScript:New to SpiderMonkey

2016-10-11T16:17:12Z

Sfink: /* Coding Style */ virtual functions are ok for random stuff, which isn't in the JS heap

== Tutorial: your first patch ==

The first step to getting involved with SpiderMonkey is to make your first patch. This guides you through it, and at the end you should have learnt a lot of the procedures and formalisms involved in getting things done here.

We'll assume you're on a Unix-y platform, and that you know what you're doing. We'll ignore nearly all details.

=== Get the code ===

Spidermonkey development happens in the "mozilla-central" mercurial repository:

hg clone http://hg.mozilla.org/mozilla-central spidermonkey

=== Build the js shell ===

Most of the time, you'll be working with the Javascript shell, instead of the full Firefox browser. So build the shell:

cd spidermonkey/js/src
cp configure.in configure && chmod +x configure # or autoconf2.13 or autoconf-2.13
mkdir build_DBG.OBJ
cd build_DBG.OBJ
../configure --enable-debug --disable-optimize
make # or make -j8
cd ..

If you're having trouble or are missing dependencies, refer to [https://developer.mozilla.org/en/SpiderMonkey/Build_Documentation#Building_SpiderMonkey_tip Building SpiderMonkey Tip].

=== Fix something ===

At this point, you're ready to make your first fix.

TODO: something useless. Maybe adding a datemicrosecond function.

==== Building your changes ====

Having made the change, build the shell again.

make -C build_DBG.OBJ

==== Testing your changes ====

It builds. Hurray. Time to run the tests to check you haven't broken anything.

jit-test/jit_test.py build_DBG.OBJ/dist/bin/js
(The location of the shell has changed, it used to be build_DBG.OBJ/js)

The jit-tests are pretty quick, and should give you an idea if you've gotten something wrong. Assuming nothing goes wrong, try the ref-tests:

tests/jstests.py build_DBG.OBJ/dist/bin/js

Note that some of these tests fail depending on the timezone and locale they're run in, so if you get any errors that don't seem related to your changes, re-run the tests with a shell build without your changes applied and compare the results.

==== Benchmark your changes ====

Tests all pass. Congrats, you didn't break anything. Now, did you make it faster or slower? We benchmark using the v8 and SunSpider benchmarks. Get the benchmarks:

svn checkout http://svn.webkit.org/repository/webkit/trunk/PerformanceTests/SunSpider

And now run them:

cd SunSpider
./sunspider --shell=../build_DBG.OBJ/dist/bin/js --run=30 --suite=sunspider-0.9.1
cd ..

===== Optimized build =====

Whoops, we benchmarked the debug version. Let's make an optimized build to test instead.

mkdir build_OPT.OBJ
cd build_OPT.OBJ
../configure --disable-debug --enable-optimize
make
cd ..

Repeat the sunspider steps above, and take note of the line that looks like:

Results are located at sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js

You'll need that later.

===== Baseline version / Mercurial Queues =====

We need to time our optimized version against the baseline version. This calls for a brief introduction to mercurial queues, which used to be the way most people managed their SpiderMonkey workflow (though these days many people use native hg, native hg + evolution, or git):

hg qinit
hg qnew my_first_patch -f
hg qrefresh

This puts your current work into a patch, managed by Mercurial, symbolically called my_first_patch. To pop the patch off:

hg qpop

And we're back to our pristine version.

===== Compare =====

Build again and rerun SunSpider again. You should now have two files like:

sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js

Compare them using the compare script:

cd SunSpider
./sunspider-compare-results --shell=../build_DBG.OBJ/js --suite=sunspider-0.9.1 FILE1-withoutPatch FILE2-withPatch

=== Get a real bug ===

At this point, you've seen nearly everything you need to do hack on SpiderMonkey. So it's time to get a real bug to work on. You can get a bug on [http://www.joshmatthews.net/bugsahoy/?jseng=1&unowned=1 Bugs Ahoy].

Fix the bug, updating the bug report with your progress, and asking questions as you go (either in the bug comments, or in [irc://irc.mozilla.org/#jsapi #jsapi]). When it's done, repeat all the steps above. Then it's time to get your patch into the tree.

=== Submit a patch ===

To get the patch from mercurial, use:

hg qdiff # if you're using queues or
hg diff # if you're not

Add it to the bug as an attachment.

=== Get a review ===

Nothing gets into the tree without a review, so you'll need one. The [[JavaScript:Hackers|SpiderMonkey hackers list]] is a good place to start: if your patch changes something listed as an area of expertise for someone there, that's a good person to ask for a review.

Alternatively run <code>hg blame</code> on the files you've changed, and check who has been changing related code recently. They're likely to be good candidates. An irc bot can automate this process for a single file if you enter "/msg mrgiggles who can review something.cpp?" into your irc client.

The review will consist of comments on your changes, suggesting or requesting alternative ways to do something and asking you to make changes where needed. They might also request additional changes, for example tests. Fix what they ask, resubmit the patch to bugzilla, and ask for another review. After you repeat this step a few times, they will mark the patch as "<code>r+</code>" meaning it's now good to commit.

=== Commit ===

You can't commit to mozilla-central / mozilla-inbound until you have "level 3" access, so you'll need someone to do this for you. Try asking in [irc://irc.mozilla.org/#jsapi #jsapi], or add the <code>checkin-needed</code> keyword to the bug. After you have been contributing for a while, you can get level 3 access by [https://www.mozilla.org/hacking/commit-access-policy/ applying for it].

After committing, a large series of tests will be run to make sure you didn't break anything. You will need to hang around to make sure you didn't break something. It is difficult to determine what failures are real and what are what we call "intermittent oranges" ("orange" because that is the color used on our continuous integration dashboard for test failures). If you do break something, a sheriff will probably let you know via IRC and will probably back your patch out. You can always ask [irc://irc.mozilla.org/#jsapi for help] determining what is going on. (Over time you'll get a feel for figuring out when breakage is real on your own.)

== Overview of the JS engine ==

The JS engine is a swiftly moving target. The most detailed information is available at https://developer.mozilla.org/en/SpiderMonkey. Here are some particularly interesting, mostly up-to-date resources:

=== High level overviews ===

(Outdated) http://hacks.mozilla.org/2010/03/a-quick-note-on-javascript-engine-components/

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals

=== Medium level documentation ===

jsapi.h: http://hg.mozilla.org/mozilla-central/file/tip/js/src/jsapi.h and the files in http://hg.mozilla.org/mozilla-central/file/tip/js/public

Frequently used coding recipes and mappings from JS idioms to SpiderMonkey code: https://developer.mozilla.org/En/SpiderMonkey/JSAPI_Cookbook

=== Detailed documentation ===

Build: https://developer.mozilla.org/en/SpiderMonkey/Build_Documentation

Testing: https://developer.mozilla.org/en/SpiderMonkey/Running_Automated_JavaScript_Tests

Shell: https://developer.mozilla.org/En/SpiderMonkey/Introduction_to_the_JavaScript_shell

Function reference: https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference

== Collaboration and teamwork ==

=== Communication (in descending order of information content) ===

Nearly all communication is handled through [https://bugzilla.mozilla.org Bugzilla]. All bugs, feature requests, issues, enhancements, etc, are all referred to as bugs. No code may enter the Mozilla repository without being a patch attached to a bugzilla bug first. To follow all SpiderMonkey related bugs:

Go to [https://bugzilla.mozilla.org/userprefs.cgi?tab=email email preferences]
Watch the user general@spidermonkey.bugs
Or watch one of the JS components in the Core product: JavaScript Engine, JavaScript Engine: JIT, JavaScript: GC, or JavaScript: Standard Library

SpiderMonkey contributors generally hang out in the very active [irc://irc.mozilla.org/jsapi #jsapi IRC channel].

The [https://www.mozilla.org/about/forums/#dev-tech-js-engine-internals js-internals mailing list] is used for communicating with other SpiderMonkey hackers. (Internals as in discussing the internals of the SpiderMonkey engine. All are welcome on the list.).

Reading Planet Mozilla is the best way to keep up with the Mozilla project, which includes some SpiderMonkey related blogs:

[https://blog.mozilla.org/javascript General JavaScript blog]
[http://blog.mozilla.com/jorendorff Jason Orendorff]
[http://blog.mozilla.com/nnethercote/ Nicholas Nethercote]
[http://whereswalden.com/ Jeff Walden]
[https://itcouldbesomuchbetter.wordpress.com Jim Blandy]
[https://jandemooij.nl/ Jan de Mooij]
[https://h4writer.com/ Hannes Verschore]
[http://rfrn.org/~shu/ Shu-yu Guo]
[https://blog.benj.me/tag/mozilla.html Benjamin Bouvier]

The [https://developer.mozilla.org/en/SpiderMonkey#Community js-engine mailing list] is generally used for communicating with people who embed SpiderMonkey, such as asking questions and announcing API changes. No actual development happens on the list.

== Code considerations ==

=== Repository ===

Most active work on SpiderMonkey is done in the [http://hg.mozilla.org/mozilla-central mozilla-central] branch of the mozilla repository.

=== Coding Style ===

For many years, SpiderMonkey was written in C, and is gradually moving to C++. We still avoid many features such as run-time type information and exceptions, and generally avoid virtual functions for core data, but have come around to the glory of templates and namespaces relatively recently. Read the [[JavaScript:SpiderMonkey:C++ Coding Style|Coding Style]]. Do NOT read the portability guidelines, which I will not link to, since they are very out of date.

=== Workflow ===

Everything goes through bugzilla. We find a bug or have an idea, then submit it to bugzilla, then file patches to solve it. When it is solved, the patch is reviewed by team members, and is then committed to the [http://hg.mozilla.org/mozilla-central mozilla-central repository]. A link to the commit is then added as a comment to the bug.

As well as committing to [http://hg.mozilla.org/mozilla-central mozilla-central], we also have the option of committing to [http://hg.mozilla.org/integration/mozilla-inbound mozilla-inbound], which is automatically merged to mozilla-central by a Sheriff. This exempts us from watching [http://tbpl.mozilla.org tinderbox] to check for errors in our patches, and commits are automatically backed out if errors are found.

==== Sample Workflows ====

(Outdated) [http://blog.mozilla.com/nnethercote/2009/07/27/how-i-work-on-tracemonkey/ Nicholas Nethercote: How I work on Tracemonkey]

=== Policy ===

The following docs are for the Mozilla project, and differ ever so slightly from what you should do for SpiderMonkey. For example, you should find reviewers in #jsapi rather than #developers.

[http://www.mozilla.org/hacking/committer/ How to get commit access]

[https://developer.mozilla.org/en/Creating_a_patch How to make patches]

[https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch Submitting a patch]

[https://developer.mozilla.org/en/Supported_build_configurations Supported Platforms]

==== .hgrc file ====

This .hgrc file contains a lot of the wisdom distilled through the wiki:

[extensions]
mq =

[ui]
username = First Last <email@domain.tld>

[alias]
qfulldiff = diff --rev qparent:.

[defaults]
diff = -p -U 8
qdiff = -p -U 8
qnew = -U
commit = -v

[diff]
git = true
showfunc = true
unified = 8

[paths]
try = ssh://email@domain.tld@hg.mozilla.org/try/

=== Try server ===

Often, you may be a little wary of breaking things. Mozilla has a [[Build:TryServer|Try Server]] where you can send a patch, and it'll be built and tested on tons of machines, which report to [http://tbpl.mozilla.org/?tree=Try TBPL]. Although you don't have [https://www.mozilla.org/hacking/commit-access-policy/ access] to TryServer just yet, you can get someone else to push it there for you. Just attach a patch to your bug, and ask in a comment, or on [irc://irc.mozilla.org/#jsapi #jsapi]. To be able to push to try-server yourself, you will need "level 1" access, which you can [https://www.mozilla.org/hacking/commit-access-policy/ request] once you've contributed a patch or two.

=== Mercurial Queues ===

Since most of our lives revolve around patches, and we use Mercurial, nearly everybody uses Mercurial queues.

Queues are based on the idea of patch management. Each queue consists of a series of patches, applied sequentially. The aim of the game is to split potential commits into simple, bite-sized chunks which are easy to review. This also makes it simple to experiment without polluting your existing work on a bug, to spin parts off into new bugs, and to rapidly apply and unapply patches (as demonstrated in the tutorial above).

==== Enabling ====

Add the following snippet to your .hgrc file to enable MQ

[extensions]
mq =

==== Example MQ workflow ====

Clone the repository to deal with a bug:

hg clone http://hg.mozilla.org/mozilla-central

Initialize your queue:

hg qinit -c

Create a new patch, with some name:

hg qnew first_attempt

Work on the patch, try to fix the bug, test, compile, etc.

Refresh (save your work into the patch):

hg qrefresh

Repeat a few times.

Rename the patch (because your first name wasn't appliable):

hg qrename refactor_the_whatsit

Create a new patch to try a logically separate part of the same bug:

hg qnew rip_out_the_old_thing

Repeat the process a few times, until you have solved the problem. During this time, it can often be useful to go back and forth between patches:

hg qpop # unapply a patch
hg qpush # reapply a patch
hg qpop -a # unapply all patches
hg qpush -a # reapply all patches

Combine all the patches into a single patch, which you submit to bugzilla:

hg qpush -a
hg qdiff --rev qparent:. > my_wonderful_patch.patch

Commit the patches to your local patch repository, in case you make a mistake (You might do this periodically):

hg qcommit -m "Some message. Doesn't have to be good, this won't be committed to the repository, it's just for you"

Go back to the old patches and fiddle with them based on feedback:

hg qpop
hg qrefresh
etc

There are some more complex techniques that we won't go into in detail. You can enable only some patches using qguard and qselect, and you can reorder the patches by manually editing the .hg/patches/series file. But be careful!

[[Category:New Contributor Landing Page]]

JavaScript:New to SpiderMonkey

2016-10-11T15:48:05Z

Sfink: /* Communication (in descending order of information content) */ component watch

== Tutorial: your first patch ==

The first step to getting involved with SpiderMonkey is to make your first patch. This guides you through it, and at the end you should have learnt a lot of the procedures and formalisms involved in getting things done here.

We'll assume you're on a Unix-y platform, and that you know what you're doing. We'll ignore nearly all details.

=== Get the code ===

Spidermonkey development happens in the "mozilla-central" mercurial repository:

hg clone http://hg.mozilla.org/mozilla-central spidermonkey

=== Build the js shell ===

Most of the time, you'll be working with the Javascript shell, instead of the full Firefox browser. So build the shell:

cd spidermonkey/js/src
cp configure.in configure && chmod +x configure # or autoconf2.13 or autoconf-2.13
mkdir build_DBG.OBJ
cd build_DBG.OBJ
../configure --enable-debug --disable-optimize
make # or make -j8
cd ..

If you're having trouble or are missing dependencies, refer to [https://developer.mozilla.org/en/SpiderMonkey/Build_Documentation#Building_SpiderMonkey_tip Building SpiderMonkey Tip].

=== Fix something ===

At this point, you're ready to make your first fix.

TODO: something useless. Maybe adding a datemicrosecond function.

==== Building your changes ====

Having made the change, build the shell again.

make -C build_DBG.OBJ

==== Testing your changes ====

It builds. Hurray. Time to run the tests to check you haven't broken anything.

jit-test/jit_test.py build_DBG.OBJ/dist/bin/js
(The location of the shell has changed, it used to be build_DBG.OBJ/js)

The jit-tests are pretty quick, and should give you an idea if you've gotten something wrong. Assuming nothing goes wrong, try the ref-tests:

tests/jstests.py build_DBG.OBJ/dist/bin/js

Note that some of these tests fail depending on the timezone and locale they're run in, so if you get any errors that don't seem related to your changes, re-run the tests with a shell build without your changes applied and compare the results.

==== Benchmark your changes ====

Tests all pass. Congrats, you didn't break anything. Now, did you make it faster or slower? We benchmark using the v8 and SunSpider benchmarks. Get the benchmarks:

svn checkout http://svn.webkit.org/repository/webkit/trunk/PerformanceTests/SunSpider

And now run them:

cd SunSpider
./sunspider --shell=../build_DBG.OBJ/dist/bin/js --run=30 --suite=sunspider-0.9.1
cd ..

===== Optimized build =====

Whoops, we benchmarked the debug version. Let's make an optimized build to test instead.

mkdir build_OPT.OBJ
cd build_OPT.OBJ
../configure --disable-debug --enable-optimize
make
cd ..

Repeat the sunspider steps above, and take note of the line that looks like:

Results are located at sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js

You'll need that later.

===== Baseline version / Mercurial Queues =====

We need to time our optimized version against the baseline version. This calls for a brief introduction to mercurial queues, which used to be the way most people managed their SpiderMonkey workflow (though these days many people use native hg, native hg + evolution, or git):

hg qinit
hg qnew my_first_patch -f
hg qrefresh

This puts your current work into a patch, managed by Mercurial, symbolically called my_first_patch. To pop the patch off:

hg qpop

And we're back to our pristine version.

===== Compare =====

Build again and rerun SunSpider again. You should now have two files like:

sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js

Compare them using the compare script:

cd SunSpider
./sunspider-compare-results --shell=../build_DBG.OBJ/js --suite=sunspider-0.9.1 FILE1-withoutPatch FILE2-withPatch

=== Get a real bug ===

At this point, you've seen nearly everything you need to do hack on SpiderMonkey. So it's time to get a real bug to work on. You can get a bug on [http://www.joshmatthews.net/bugsahoy/?jseng=1&unowned=1 Bugs Ahoy].

Fix the bug, updating the bug report with your progress, and asking questions as you go (either in the bug comments, or in [irc://irc.mozilla.org/#jsapi #jsapi]). When it's done, repeat all the steps above. Then it's time to get your patch into the tree.

=== Submit a patch ===

To get the patch from mercurial, use:

hg qdiff # if you're using queues or
hg diff # if you're not

Add it to the bug as an attachment.

=== Get a review ===

Nothing gets into the tree without a review, so you'll need one. The [[JavaScript:Hackers|SpiderMonkey hackers list]] is a good place to start: if your patch changes something listed as an area of expertise for someone there, that's a good person to ask for a review.

Alternatively run <code>hg blame</code> on the files you've changed, and check who has been changing related code recently. They're likely to be good candidates. An irc bot can automate this process for a single file if you enter "/msg mrgiggles who can review something.cpp?" into your irc client.

The review will consist of comments on your changes, suggesting or requesting alternative ways to do something and asking you to make changes where needed. They might also request additional changes, for example tests. Fix what they ask, resubmit the patch to bugzilla, and ask for another review. After you repeat this step a few times, they will mark the patch as "<code>r+</code>" meaning it's now good to commit.

=== Commit ===

You can't commit to mozilla-central / mozilla-inbound until you have "level 3" access, so you'll need someone to do this for you. Try asking in [irc://irc.mozilla.org/#jsapi #jsapi], or add the <code>checkin-needed</code> keyword to the bug. After you have been contributing for a while, you can get level 3 access by [https://www.mozilla.org/hacking/commit-access-policy/ applying for it].

After committing, a large series of tests will be run to make sure you didn't break anything. You will need to hang around to make sure you didn't break something. It is difficult to determine what failures are real and what are what we call "intermittent oranges" ("orange" because that is the color used on our continuous integration dashboard for test failures). If you do break something, a sheriff will probably let you know via IRC and will probably back your patch out. You can always ask [irc://irc.mozilla.org/#jsapi for help] determining what is going on. (Over time you'll get a feel for figuring out when breakage is real on your own.)

== Overview of the JS engine ==

The JS engine is a swiftly moving target. The most detailed information is available at https://developer.mozilla.org/en/SpiderMonkey. Here are some particularly interesting, mostly up-to-date resources:

=== High level overviews ===

(Outdated) http://hacks.mozilla.org/2010/03/a-quick-note-on-javascript-engine-components/

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals

=== Medium level documentation ===

jsapi.h: http://hg.mozilla.org/mozilla-central/file/tip/js/src/jsapi.h and the files in http://hg.mozilla.org/mozilla-central/file/tip/js/public

Frequently used coding recipes and mappings from JS idioms to SpiderMonkey code: https://developer.mozilla.org/En/SpiderMonkey/JSAPI_Cookbook

=== Detailed documentation ===

Build: https://developer.mozilla.org/en/SpiderMonkey/Build_Documentation

Testing: https://developer.mozilla.org/en/SpiderMonkey/Running_Automated_JavaScript_Tests

Shell: https://developer.mozilla.org/En/SpiderMonkey/Introduction_to_the_JavaScript_shell

Function reference: https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference

== Collaboration and teamwork ==

=== Communication (in descending order of information content) ===

Nearly all communication is handled through [https://bugzilla.mozilla.org Bugzilla]. All bugs, feature requests, issues, enhancements, etc, are all referred to as bugs. No code may enter the Mozilla repository without being a patch attached to a bugzilla bug first. To follow all SpiderMonkey related bugs:

Go to [https://bugzilla.mozilla.org/userprefs.cgi?tab=email email preferences]
Watch the user general@spidermonkey.bugs
Or watch one of the JS components in the Core product: JavaScript Engine, JavaScript Engine: JIT, JavaScript: GC, or JavaScript: Standard Library

SpiderMonkey contributors generally hang out in the very active [irc://irc.mozilla.org/jsapi #jsapi IRC channel].

The [https://www.mozilla.org/about/forums/#dev-tech-js-engine-internals js-internals mailing list] is used for communicating with other SpiderMonkey hackers. (Internals as in discussing the internals of the SpiderMonkey engine. All are welcome on the list.).

Reading Planet Mozilla is the best way to keep up with the Mozilla project, which includes some SpiderMonkey related blogs:

[https://blog.mozilla.org/javascript General JavaScript blog]
[http://blog.mozilla.com/jorendorff Jason Orendorff]
[http://blog.mozilla.com/nnethercote/ Nicholas Nethercote]
[http://whereswalden.com/ Jeff Walden]
[https://itcouldbesomuchbetter.wordpress.com Jim Blandy]
[https://jandemooij.nl/ Jan de Mooij]
[https://h4writer.com/ Hannes Verschore]
[http://rfrn.org/~shu/ Shu-yu Guo]
[https://blog.benj.me/tag/mozilla.html Benjamin Bouvier]

The [https://developer.mozilla.org/en/SpiderMonkey#Community js-engine mailing list] is generally used for communicating with people who embed SpiderMonkey, such as asking questions and announcing API changes. No actual development happens on the list.

== Code considerations ==

=== Repository ===

Most active work on SpiderMonkey is done in the [http://hg.mozilla.org/mozilla-central mozilla-central] branch of the mozilla repository.

=== Coding Style ===

For many years, SpiderMonkey was written in C, and is gradually moving to C++. We still avoid many features such as run-time type information and virtual functions, but have come around to the glory of templates and namespaces relatively recently. Read the [[JavaScript:SpiderMonkey:C++ Coding Style|Coding Style]]. Do NOT read the portability guidelines, which I will not link to, since they are very out of date.

=== Workflow ===

Everything goes through bugzilla. We find a bug or have an idea, then submit it to bugzilla, then file patches to solve it. When it is solved, the patch is reviewed by team members, and is then committed to the [http://hg.mozilla.org/mozilla-central mozilla-central repository]. A link to the commit is then added as a comment to the bug.

As well as committing to [http://hg.mozilla.org/mozilla-central mozilla-central], we also have the option of committing to [http://hg.mozilla.org/integration/mozilla-inbound mozilla-inbound], which is automatically merged to mozilla-central by a Sheriff. This exempts us from watching [http://tbpl.mozilla.org tinderbox] to check for errors in our patches, and commits are automatically backed out if errors are found.

==== Sample Workflows ====

(Outdated) [http://blog.mozilla.com/nnethercote/2009/07/27/how-i-work-on-tracemonkey/ Nicholas Nethercote: How I work on Tracemonkey]

=== Policy ===

The following docs are for the Mozilla project, and differ ever so slightly from what you should do for SpiderMonkey. For example, you should find reviewers in #jsapi rather than #developers.

[http://www.mozilla.org/hacking/committer/ How to get commit access]

[https://developer.mozilla.org/en/Creating_a_patch How to make patches]

[https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch Submitting a patch]

[https://developer.mozilla.org/en/Supported_build_configurations Supported Platforms]

==== .hgrc file ====

This .hgrc file contains a lot of the wisdom distilled through the wiki:

[extensions]
mq =

[ui]
username = First Last <email@domain.tld>

[alias]
qfulldiff = diff --rev qparent:.

[defaults]
diff = -p -U 8
qdiff = -p -U 8
qnew = -U
commit = -v

[diff]
git = true
showfunc = true
unified = 8

[paths]
try = ssh://email@domain.tld@hg.mozilla.org/try/

=== Try server ===

Often, you may be a little wary of breaking things. Mozilla has a [[Build:TryServer|Try Server]] where you can send a patch, and it'll be built and tested on tons of machines, which report to [http://tbpl.mozilla.org/?tree=Try TBPL]. Although you don't have [https://www.mozilla.org/hacking/commit-access-policy/ access] to TryServer just yet, you can get someone else to push it there for you. Just attach a patch to your bug, and ask in a comment, or on [irc://irc.mozilla.org/#jsapi #jsapi]. To be able to push to try-server yourself, you will need "level 1" access, which you can [https://www.mozilla.org/hacking/commit-access-policy/ request] once you've contributed a patch or two.

=== Mercurial Queues ===

Since most of our lives revolve around patches, and we use Mercurial, nearly everybody uses Mercurial queues.

Queues are based on the idea of patch management. Each queue consists of a series of patches, applied sequentially. The aim of the game is to split potential commits into simple, bite-sized chunks which are easy to review. This also makes it simple to experiment without polluting your existing work on a bug, to spin parts off into new bugs, and to rapidly apply and unapply patches (as demonstrated in the tutorial above).

==== Enabling ====

Add the following snippet to your .hgrc file to enable MQ

[extensions]
mq =

==== Example MQ workflow ====

Clone the repository to deal with a bug:

hg clone http://hg.mozilla.org/mozilla-central

Initialize your queue:

hg qinit -c

Create a new patch, with some name:

hg qnew first_attempt

Work on the patch, try to fix the bug, test, compile, etc.

Refresh (save your work into the patch):

hg qrefresh

Repeat a few times.

Rename the patch (because your first name wasn't appliable):

hg qrename refactor_the_whatsit

Create a new patch to try a logically separate part of the same bug:

hg qnew rip_out_the_old_thing

Repeat the process a few times, until you have solved the problem. During this time, it can often be useful to go back and forth between patches:

hg qpop # unapply a patch
hg qpush # reapply a patch
hg qpop -a # unapply all patches
hg qpush -a # reapply all patches

Combine all the patches into a single patch, which you submit to bugzilla:

hg qpush -a
hg qdiff --rev qparent:. > my_wonderful_patch.patch

Commit the patches to your local patch repository, in case you make a mistake (You might do this periodically):

hg qcommit -m "Some message. Doesn't have to be good, this won't be committed to the repository, it's just for you"

Go back to the old patches and fiddle with them based on feedback:

hg qpop
hg qrefresh
etc

There are some more complex techniques that we won't go into in detail. You can enable only some patches using qguard and qselect, and you can reorder the patches by manually editing the .hg/patches/series file. But be careful!

[[Category:New Contributor Landing Page]]

JavaScript:New to SpiderMonkey

2016-10-11T15:45:20Z

Sfink: /* Medium level documentation */ js/public

== Tutorial: your first patch ==

The first step to getting involved with SpiderMonkey is to make your first patch. This guides you through it, and at the end you should have learnt a lot of the procedures and formalisms involved in getting things done here.

We'll assume you're on a Unix-y platform, and that you know what you're doing. We'll ignore nearly all details.

=== Get the code ===

Spidermonkey development happens in the "mozilla-central" mercurial repository:

hg clone http://hg.mozilla.org/mozilla-central spidermonkey

=== Build the js shell ===

Most of the time, you'll be working with the Javascript shell, instead of the full Firefox browser. So build the shell:

cd spidermonkey/js/src
cp configure.in configure && chmod +x configure # or autoconf2.13 or autoconf-2.13
mkdir build_DBG.OBJ
cd build_DBG.OBJ
../configure --enable-debug --disable-optimize
make # or make -j8
cd ..

If you're having trouble or are missing dependencies, refer to [https://developer.mozilla.org/en/SpiderMonkey/Build_Documentation#Building_SpiderMonkey_tip Building SpiderMonkey Tip].

=== Fix something ===

At this point, you're ready to make your first fix.

TODO: something useless. Maybe adding a datemicrosecond function.

==== Building your changes ====

Having made the change, build the shell again.

make -C build_DBG.OBJ

==== Testing your changes ====

It builds. Hurray. Time to run the tests to check you haven't broken anything.

jit-test/jit_test.py build_DBG.OBJ/dist/bin/js
(The location of the shell has changed, it used to be build_DBG.OBJ/js)

The jit-tests are pretty quick, and should give you an idea if you've gotten something wrong. Assuming nothing goes wrong, try the ref-tests:

tests/jstests.py build_DBG.OBJ/dist/bin/js

Note that some of these tests fail depending on the timezone and locale they're run in, so if you get any errors that don't seem related to your changes, re-run the tests with a shell build without your changes applied and compare the results.

==== Benchmark your changes ====

Tests all pass. Congrats, you didn't break anything. Now, did you make it faster or slower? We benchmark using the v8 and SunSpider benchmarks. Get the benchmarks:

svn checkout http://svn.webkit.org/repository/webkit/trunk/PerformanceTests/SunSpider

And now run them:

cd SunSpider
./sunspider --shell=../build_DBG.OBJ/dist/bin/js --run=30 --suite=sunspider-0.9.1
cd ..

===== Optimized build =====

Whoops, we benchmarked the debug version. Let's make an optimized build to test instead.

mkdir build_OPT.OBJ
cd build_OPT.OBJ
../configure --disable-debug --enable-optimize
make
cd ..

Repeat the sunspider steps above, and take note of the line that looks like:

Results are located at sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js

You'll need that later.

===== Baseline version / Mercurial Queues =====

We need to time our optimized version against the baseline version. This calls for a brief introduction to mercurial queues, which used to be the way most people managed their SpiderMonkey workflow (though these days many people use native hg, native hg + evolution, or git):

hg qinit
hg qnew my_first_patch -f
hg qrefresh

This puts your current work into a patch, managed by Mercurial, symbolically called my_first_patch. To pop the patch off:

hg qpop

And we're back to our pristine version.

===== Compare =====

Build again and rerun SunSpider again. You should now have two files like:

sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js

Compare them using the compare script:

cd SunSpider
./sunspider-compare-results --shell=../build_DBG.OBJ/js --suite=sunspider-0.9.1 FILE1-withoutPatch FILE2-withPatch

=== Get a real bug ===

At this point, you've seen nearly everything you need to do hack on SpiderMonkey. So it's time to get a real bug to work on. You can get a bug on [http://www.joshmatthews.net/bugsahoy/?jseng=1&unowned=1 Bugs Ahoy].

Fix the bug, updating the bug report with your progress, and asking questions as you go (either in the bug comments, or in [irc://irc.mozilla.org/#jsapi #jsapi]). When it's done, repeat all the steps above. Then it's time to get your patch into the tree.

=== Submit a patch ===

To get the patch from mercurial, use:

hg qdiff # if you're using queues or
hg diff # if you're not

Add it to the bug as an attachment.

=== Get a review ===

Nothing gets into the tree without a review, so you'll need one. The [[JavaScript:Hackers|SpiderMonkey hackers list]] is a good place to start: if your patch changes something listed as an area of expertise for someone there, that's a good person to ask for a review.

Alternatively run <code>hg blame</code> on the files you've changed, and check who has been changing related code recently. They're likely to be good candidates. An irc bot can automate this process for a single file if you enter "/msg mrgiggles who can review something.cpp?" into your irc client.

The review will consist of comments on your changes, suggesting or requesting alternative ways to do something and asking you to make changes where needed. They might also request additional changes, for example tests. Fix what they ask, resubmit the patch to bugzilla, and ask for another review. After you repeat this step a few times, they will mark the patch as "<code>r+</code>" meaning it's now good to commit.

=== Commit ===

You can't commit to mozilla-central / mozilla-inbound until you have "level 3" access, so you'll need someone to do this for you. Try asking in [irc://irc.mozilla.org/#jsapi #jsapi], or add the <code>checkin-needed</code> keyword to the bug. After you have been contributing for a while, you can get level 3 access by [https://www.mozilla.org/hacking/commit-access-policy/ applying for it].

After committing, a large series of tests will be run to make sure you didn't break anything. You will need to hang around to make sure you didn't break something. It is difficult to determine what failures are real and what are what we call "intermittent oranges" ("orange" because that is the color used on our continuous integration dashboard for test failures). If you do break something, a sheriff will probably let you know via IRC and will probably back your patch out. You can always ask [irc://irc.mozilla.org/#jsapi for help] determining what is going on. (Over time you'll get a feel for figuring out when breakage is real on your own.)

== Overview of the JS engine ==

The JS engine is a swiftly moving target. The most detailed information is available at https://developer.mozilla.org/en/SpiderMonkey. Here are some particularly interesting, mostly up-to-date resources:

=== High level overviews ===

(Outdated) http://hacks.mozilla.org/2010/03/a-quick-note-on-javascript-engine-components/

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals

=== Medium level documentation ===

jsapi.h: http://hg.mozilla.org/mozilla-central/file/tip/js/src/jsapi.h and the files in http://hg.mozilla.org/mozilla-central/file/tip/js/public

Frequently used coding recipes and mappings from JS idioms to SpiderMonkey code: https://developer.mozilla.org/En/SpiderMonkey/JSAPI_Cookbook

=== Detailed documentation ===

Build: https://developer.mozilla.org/en/SpiderMonkey/Build_Documentation

Testing: https://developer.mozilla.org/en/SpiderMonkey/Running_Automated_JavaScript_Tests

Shell: https://developer.mozilla.org/En/SpiderMonkey/Introduction_to_the_JavaScript_shell

Function reference: https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference

== Collaboration and teamwork ==

=== Communication (in descending order of information content) ===

Nearly all communication is handled through [https://bugzilla.mozilla.org Bugzilla]. All bugs, feature requests, issues, enhancements, etc, are all referred to as bugs. No code may enter the Mozilla repository without being a patch attached to a bugzilla bug first. To follow all SpiderMonkey related bugs:

Go to [https://bugzilla.mozilla.org/userprefs.cgi?tab=email email preferences]
Watch the user general@spidermonkey.bugs

SpiderMonkey contributors generally hang out in the very active [irc://irc.mozilla.org/jsapi #jsapi IRC channel].

The [https://www.mozilla.org/about/forums/#dev-tech-js-engine-internals js-internals mailing list] is used for communicating with other SpiderMonkey hackers. (Internals as in discussing the internals of the SpiderMonkey engine. All are welcome on the list.).

Reading Planet Mozilla is the best way to keep up with the Mozilla project, which includes some SpiderMonkey related blogs:

[https://blog.mozilla.org/javascript General JavaScript blog]
[http://blog.mozilla.com/jorendorff Jason Orendorff]
[http://blog.mozilla.com/nnethercote/ Nicholas Nethercote]
[http://whereswalden.com/ Jeff Walden]
[https://itcouldbesomuchbetter.wordpress.com Jim Blandy]
[https://jandemooij.nl/ Jan de Mooij]
[https://h4writer.com/ Hannes Verschore]
[http://rfrn.org/~shu/ Shu-yu Guo]
[https://blog.benj.me/tag/mozilla.html Benjamin Bouvier]

The [https://developer.mozilla.org/en/SpiderMonkey#Community js-engine mailing list] is generally used for communicating with people who embed SpiderMonkey, such as asking questions and announcing API changes. No actual development happens on the list.

== Code considerations ==

=== Repository ===

Most active work on SpiderMonkey is done in the [http://hg.mozilla.org/mozilla-central mozilla-central] branch of the mozilla repository.

=== Coding Style ===

For many years, SpiderMonkey was written in C, and is gradually moving to C++. We still avoid many features such as run-time type information and virtual functions, but have come around to the glory of templates and namespaces relatively recently. Read the [[JavaScript:SpiderMonkey:C++ Coding Style|Coding Style]]. Do NOT read the portability guidelines, which I will not link to, since they are very out of date.

=== Workflow ===

Everything goes through bugzilla. We find a bug or have an idea, then submit it to bugzilla, then file patches to solve it. When it is solved, the patch is reviewed by team members, and is then committed to the [http://hg.mozilla.org/mozilla-central mozilla-central repository]. A link to the commit is then added as a comment to the bug.

As well as committing to [http://hg.mozilla.org/mozilla-central mozilla-central], we also have the option of committing to [http://hg.mozilla.org/integration/mozilla-inbound mozilla-inbound], which is automatically merged to mozilla-central by a Sheriff. This exempts us from watching [http://tbpl.mozilla.org tinderbox] to check for errors in our patches, and commits are automatically backed out if errors are found.

==== Sample Workflows ====

(Outdated) [http://blog.mozilla.com/nnethercote/2009/07/27/how-i-work-on-tracemonkey/ Nicholas Nethercote: How I work on Tracemonkey]

=== Policy ===

The following docs are for the Mozilla project, and differ ever so slightly from what you should do for SpiderMonkey. For example, you should find reviewers in #jsapi rather than #developers.

[http://www.mozilla.org/hacking/committer/ How to get commit access]

[https://developer.mozilla.org/en/Creating_a_patch How to make patches]

[https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch Submitting a patch]

[https://developer.mozilla.org/en/Supported_build_configurations Supported Platforms]

==== .hgrc file ====

This .hgrc file contains a lot of the wisdom distilled through the wiki:

[extensions]
mq =

[ui]
username = First Last <email@domain.tld>

[alias]
qfulldiff = diff --rev qparent:.

[defaults]
diff = -p -U 8
qdiff = -p -U 8
qnew = -U
commit = -v

[diff]
git = true
showfunc = true
unified = 8

[paths]
try = ssh://email@domain.tld@hg.mozilla.org/try/

=== Try server ===

Often, you may be a little wary of breaking things. Mozilla has a [[Build:TryServer|Try Server]] where you can send a patch, and it'll be built and tested on tons of machines, which report to [http://tbpl.mozilla.org/?tree=Try TBPL]. Although you don't have [https://www.mozilla.org/hacking/commit-access-policy/ access] to TryServer just yet, you can get someone else to push it there for you. Just attach a patch to your bug, and ask in a comment, or on [irc://irc.mozilla.org/#jsapi #jsapi]. To be able to push to try-server yourself, you will need "level 1" access, which you can [https://www.mozilla.org/hacking/commit-access-policy/ request] once you've contributed a patch or two.

=== Mercurial Queues ===

Since most of our lives revolve around patches, and we use Mercurial, nearly everybody uses Mercurial queues.

Queues are based on the idea of patch management. Each queue consists of a series of patches, applied sequentially. The aim of the game is to split potential commits into simple, bite-sized chunks which are easy to review. This also makes it simple to experiment without polluting your existing work on a bug, to spin parts off into new bugs, and to rapidly apply and unapply patches (as demonstrated in the tutorial above).

==== Enabling ====

Add the following snippet to your .hgrc file to enable MQ

[extensions]
mq =

==== Example MQ workflow ====

Clone the repository to deal with a bug:

hg clone http://hg.mozilla.org/mozilla-central

Initialize your queue:

hg qinit -c

Create a new patch, with some name:

hg qnew first_attempt

Work on the patch, try to fix the bug, test, compile, etc.

Refresh (save your work into the patch):

hg qrefresh

Repeat a few times.

Rename the patch (because your first name wasn't appliable):

hg qrename refactor_the_whatsit

Create a new patch to try a logically separate part of the same bug:

hg qnew rip_out_the_old_thing

Repeat the process a few times, until you have solved the problem. During this time, it can often be useful to go back and forth between patches:

hg qpop # unapply a patch
hg qpush # reapply a patch
hg qpop -a # unapply all patches
hg qpush -a # reapply all patches

Combine all the patches into a single patch, which you submit to bugzilla:

hg qpush -a
hg qdiff --rev qparent:. > my_wonderful_patch.patch

Commit the patches to your local patch repository, in case you make a mistake (You might do this periodically):

hg qcommit -m "Some message. Doesn't have to be good, this won't be committed to the repository, it's just for you"

Go back to the old patches and fiddle with them based on feedback:

hg qpop
hg qrefresh
etc

There are some more complex techniques that we won't go into in detail. You can enable only some patches using qguard and qselect, and you can reorder the patches by manually editing the .hg/patches/series file. But be careful!

[[Category:New Contributor Landing Page]]

JavaScript:New to SpiderMonkey

2016-10-11T15:44:39Z

Sfink: /* Commit */ sheriffs watch our backs

== Tutorial: your first patch ==

The first step to getting involved with SpiderMonkey is to make your first patch. This guides you through it, and at the end you should have learnt a lot of the procedures and formalisms involved in getting things done here.

We'll assume you're on a Unix-y platform, and that you know what you're doing. We'll ignore nearly all details.

=== Get the code ===

Spidermonkey development happens in the "mozilla-central" mercurial repository:

hg clone http://hg.mozilla.org/mozilla-central spidermonkey

=== Build the js shell ===

Most of the time, you'll be working with the Javascript shell, instead of the full Firefox browser. So build the shell:

cd spidermonkey/js/src
cp configure.in configure && chmod +x configure # or autoconf2.13 or autoconf-2.13
mkdir build_DBG.OBJ
cd build_DBG.OBJ
../configure --enable-debug --disable-optimize
make # or make -j8
cd ..

If you're having trouble or are missing dependencies, refer to [https://developer.mozilla.org/en/SpiderMonkey/Build_Documentation#Building_SpiderMonkey_tip Building SpiderMonkey Tip].

=== Fix something ===

At this point, you're ready to make your first fix.

TODO: something useless. Maybe adding a datemicrosecond function.

==== Building your changes ====

Having made the change, build the shell again.

make -C build_DBG.OBJ

==== Testing your changes ====

It builds. Hurray. Time to run the tests to check you haven't broken anything.

jit-test/jit_test.py build_DBG.OBJ/dist/bin/js
(The location of the shell has changed, it used to be build_DBG.OBJ/js)

The jit-tests are pretty quick, and should give you an idea if you've gotten something wrong. Assuming nothing goes wrong, try the ref-tests:

tests/jstests.py build_DBG.OBJ/dist/bin/js

Note that some of these tests fail depending on the timezone and locale they're run in, so if you get any errors that don't seem related to your changes, re-run the tests with a shell build without your changes applied and compare the results.

==== Benchmark your changes ====

Tests all pass. Congrats, you didn't break anything. Now, did you make it faster or slower? We benchmark using the v8 and SunSpider benchmarks. Get the benchmarks:

svn checkout http://svn.webkit.org/repository/webkit/trunk/PerformanceTests/SunSpider

And now run them:

cd SunSpider
./sunspider --shell=../build_DBG.OBJ/dist/bin/js --run=30 --suite=sunspider-0.9.1
cd ..

===== Optimized build =====

Whoops, we benchmarked the debug version. Let's make an optimized build to test instead.

mkdir build_OPT.OBJ
cd build_OPT.OBJ
../configure --disable-debug --enable-optimize
make
cd ..

Repeat the sunspider steps above, and take note of the line that looks like:

Results are located at sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js

You'll need that later.

===== Baseline version / Mercurial Queues =====

We need to time our optimized version against the baseline version. This calls for a brief introduction to mercurial queues, which used to be the way most people managed their SpiderMonkey workflow (though these days many people use native hg, native hg + evolution, or git):

hg qinit
hg qnew my_first_patch -f
hg qrefresh

This puts your current work into a patch, managed by Mercurial, symbolically called my_first_patch. To pop the patch off:

hg qpop

And we're back to our pristine version.

===== Compare =====

Build again and rerun SunSpider again. You should now have two files like:

sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js

Compare them using the compare script:

cd SunSpider
./sunspider-compare-results --shell=../build_DBG.OBJ/js --suite=sunspider-0.9.1 FILE1-withoutPatch FILE2-withPatch

=== Get a real bug ===

At this point, you've seen nearly everything you need to do hack on SpiderMonkey. So it's time to get a real bug to work on. You can get a bug on [http://www.joshmatthews.net/bugsahoy/?jseng=1&unowned=1 Bugs Ahoy].

Fix the bug, updating the bug report with your progress, and asking questions as you go (either in the bug comments, or in [irc://irc.mozilla.org/#jsapi #jsapi]). When it's done, repeat all the steps above. Then it's time to get your patch into the tree.

=== Submit a patch ===

To get the patch from mercurial, use:

hg qdiff # if you're using queues or
hg diff # if you're not

Add it to the bug as an attachment.

=== Get a review ===

Nothing gets into the tree without a review, so you'll need one. The [[JavaScript:Hackers|SpiderMonkey hackers list]] is a good place to start: if your patch changes something listed as an area of expertise for someone there, that's a good person to ask for a review.

Alternatively run <code>hg blame</code> on the files you've changed, and check who has been changing related code recently. They're likely to be good candidates. An irc bot can automate this process for a single file if you enter "/msg mrgiggles who can review something.cpp?" into your irc client.

The review will consist of comments on your changes, suggesting or requesting alternative ways to do something and asking you to make changes where needed. They might also request additional changes, for example tests. Fix what they ask, resubmit the patch to bugzilla, and ask for another review. After you repeat this step a few times, they will mark the patch as "<code>r+</code>" meaning it's now good to commit.

=== Commit ===

You can't commit to mozilla-central / mozilla-inbound until you have "level 3" access, so you'll need someone to do this for you. Try asking in [irc://irc.mozilla.org/#jsapi #jsapi], or add the <code>checkin-needed</code> keyword to the bug. After you have been contributing for a while, you can get level 3 access by [https://www.mozilla.org/hacking/commit-access-policy/ applying for it].

After committing, a large series of tests will be run to make sure you didn't break anything. You will need to hang around to make sure you didn't break something. It is difficult to determine what failures are real and what are what we call "intermittent oranges" ("orange" because that is the color used on our continuous integration dashboard for test failures). If you do break something, a sheriff will probably let you know via IRC and will probably back your patch out. You can always ask [irc://irc.mozilla.org/#jsapi for help] determining what is going on. (Over time you'll get a feel for figuring out when breakage is real on your own.)

== Overview of the JS engine ==

The JS engine is a swiftly moving target. The most detailed information is available at https://developer.mozilla.org/en/SpiderMonkey. Here are some particularly interesting, mostly up-to-date resources:

=== High level overviews ===

(Outdated) http://hacks.mozilla.org/2010/03/a-quick-note-on-javascript-engine-components/

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals

=== Medium level documentation ===

jsapi.h: http://hg.mozilla.org/mozilla-central/file/tip/js/src/jsapi.h

Frequently used coding recipes and mappings from JS idioms to SpiderMonkey code: https://developer.mozilla.org/En/SpiderMonkey/JSAPI_Cookbook

=== Detailed documentation ===

Build: https://developer.mozilla.org/en/SpiderMonkey/Build_Documentation

Testing: https://developer.mozilla.org/en/SpiderMonkey/Running_Automated_JavaScript_Tests

Shell: https://developer.mozilla.org/En/SpiderMonkey/Introduction_to_the_JavaScript_shell

Function reference: https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference

== Collaboration and teamwork ==

=== Communication (in descending order of information content) ===

Nearly all communication is handled through [https://bugzilla.mozilla.org Bugzilla]. All bugs, feature requests, issues, enhancements, etc, are all referred to as bugs. No code may enter the Mozilla repository without being a patch attached to a bugzilla bug first. To follow all SpiderMonkey related bugs:

Go to [https://bugzilla.mozilla.org/userprefs.cgi?tab=email email preferences]
Watch the user general@spidermonkey.bugs

SpiderMonkey contributors generally hang out in the very active [irc://irc.mozilla.org/jsapi #jsapi IRC channel].

The [https://www.mozilla.org/about/forums/#dev-tech-js-engine-internals js-internals mailing list] is used for communicating with other SpiderMonkey hackers. (Internals as in discussing the internals of the SpiderMonkey engine. All are welcome on the list.).

Reading Planet Mozilla is the best way to keep up with the Mozilla project, which includes some SpiderMonkey related blogs:

[https://blog.mozilla.org/javascript General JavaScript blog]
[http://blog.mozilla.com/jorendorff Jason Orendorff]
[http://blog.mozilla.com/nnethercote/ Nicholas Nethercote]
[http://whereswalden.com/ Jeff Walden]
[https://itcouldbesomuchbetter.wordpress.com Jim Blandy]
[https://jandemooij.nl/ Jan de Mooij]
[https://h4writer.com/ Hannes Verschore]
[http://rfrn.org/~shu/ Shu-yu Guo]
[https://blog.benj.me/tag/mozilla.html Benjamin Bouvier]

The [https://developer.mozilla.org/en/SpiderMonkey#Community js-engine mailing list] is generally used for communicating with people who embed SpiderMonkey, such as asking questions and announcing API changes. No actual development happens on the list.

== Code considerations ==

=== Repository ===

Most active work on SpiderMonkey is done in the [http://hg.mozilla.org/mozilla-central mozilla-central] branch of the mozilla repository.

=== Coding Style ===

For many years, SpiderMonkey was written in C, and is gradually moving to C++. We still avoid many features such as run-time type information and virtual functions, but have come around to the glory of templates and namespaces relatively recently. Read the [[JavaScript:SpiderMonkey:C++ Coding Style|Coding Style]]. Do NOT read the portability guidelines, which I will not link to, since they are very out of date.

=== Workflow ===

Everything goes through bugzilla. We find a bug or have an idea, then submit it to bugzilla, then file patches to solve it. When it is solved, the patch is reviewed by team members, and is then committed to the [http://hg.mozilla.org/mozilla-central mozilla-central repository]. A link to the commit is then added as a comment to the bug.

As well as committing to [http://hg.mozilla.org/mozilla-central mozilla-central], we also have the option of committing to [http://hg.mozilla.org/integration/mozilla-inbound mozilla-inbound], which is automatically merged to mozilla-central by a Sheriff. This exempts us from watching [http://tbpl.mozilla.org tinderbox] to check for errors in our patches, and commits are automatically backed out if errors are found.

==== Sample Workflows ====

(Outdated) [http://blog.mozilla.com/nnethercote/2009/07/27/how-i-work-on-tracemonkey/ Nicholas Nethercote: How I work on Tracemonkey]

=== Policy ===

The following docs are for the Mozilla project, and differ ever so slightly from what you should do for SpiderMonkey. For example, you should find reviewers in #jsapi rather than #developers.

[http://www.mozilla.org/hacking/committer/ How to get commit access]

[https://developer.mozilla.org/en/Creating_a_patch How to make patches]

[https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch Submitting a patch]

[https://developer.mozilla.org/en/Supported_build_configurations Supported Platforms]

==== .hgrc file ====

This .hgrc file contains a lot of the wisdom distilled through the wiki:

[extensions]
mq =

[ui]
username = First Last <email@domain.tld>

[alias]
qfulldiff = diff --rev qparent:.

[defaults]
diff = -p -U 8
qdiff = -p -U 8
qnew = -U
commit = -v

[diff]
git = true
showfunc = true
unified = 8

[paths]
try = ssh://email@domain.tld@hg.mozilla.org/try/

=== Try server ===

Often, you may be a little wary of breaking things. Mozilla has a [[Build:TryServer|Try Server]] where you can send a patch, and it'll be built and tested on tons of machines, which report to [http://tbpl.mozilla.org/?tree=Try TBPL]. Although you don't have [https://www.mozilla.org/hacking/commit-access-policy/ access] to TryServer just yet, you can get someone else to push it there for you. Just attach a patch to your bug, and ask in a comment, or on [irc://irc.mozilla.org/#jsapi #jsapi]. To be able to push to try-server yourself, you will need "level 1" access, which you can [https://www.mozilla.org/hacking/commit-access-policy/ request] once you've contributed a patch or two.

=== Mercurial Queues ===

Since most of our lives revolve around patches, and we use Mercurial, nearly everybody uses Mercurial queues.

Queues are based on the idea of patch management. Each queue consists of a series of patches, applied sequentially. The aim of the game is to split potential commits into simple, bite-sized chunks which are easy to review. This also makes it simple to experiment without polluting your existing work on a bug, to spin parts off into new bugs, and to rapidly apply and unapply patches (as demonstrated in the tutorial above).

==== Enabling ====

Add the following snippet to your .hgrc file to enable MQ

[extensions]
mq =

==== Example MQ workflow ====

Clone the repository to deal with a bug:

hg clone http://hg.mozilla.org/mozilla-central

Initialize your queue:

hg qinit -c

Create a new patch, with some name:

hg qnew first_attempt

Work on the patch, try to fix the bug, test, compile, etc.

Refresh (save your work into the patch):

hg qrefresh

Repeat a few times.

Rename the patch (because your first name wasn't appliable):

hg qrename refactor_the_whatsit

Create a new patch to try a logically separate part of the same bug:

hg qnew rip_out_the_old_thing

Repeat the process a few times, until you have solved the problem. During this time, it can often be useful to go back and forth between patches:

hg qpop # unapply a patch
hg qpush # reapply a patch
hg qpop -a # unapply all patches
hg qpush -a # reapply all patches

Combine all the patches into a single patch, which you submit to bugzilla:

hg qpush -a
hg qdiff --rev qparent:. > my_wonderful_patch.patch

Commit the patches to your local patch repository, in case you make a mistake (You might do this periodically):

hg qcommit -m "Some message. Doesn't have to be good, this won't be committed to the repository, it's just for you"

Go back to the old patches and fiddle with them based on feedback:

hg qpop
hg qrefresh
etc

There are some more complex techniques that we won't go into in detail. You can enable only some patches using qguard and qselect, and you can reorder the patches by manually editing the .hg/patches/series file. But be careful!

[[Category:New Contributor Landing Page]]

JavaScript:New to SpiderMonkey

2016-10-11T15:40:58Z

Sfink: /* Get a review */ mrgiggles

== Tutorial: your first patch ==

The first step to getting involved with SpiderMonkey is to make your first patch. This guides you through it, and at the end you should have learnt a lot of the procedures and formalisms involved in getting things done here.

We'll assume you're on a Unix-y platform, and that you know what you're doing. We'll ignore nearly all details.

=== Get the code ===

Spidermonkey development happens in the "mozilla-central" mercurial repository:

hg clone http://hg.mozilla.org/mozilla-central spidermonkey

=== Build the js shell ===

Most of the time, you'll be working with the Javascript shell, instead of the full Firefox browser. So build the shell:

cd spidermonkey/js/src
cp configure.in configure && chmod +x configure # or autoconf2.13 or autoconf-2.13
mkdir build_DBG.OBJ
cd build_DBG.OBJ
../configure --enable-debug --disable-optimize
make # or make -j8
cd ..

If you're having trouble or are missing dependencies, refer to [https://developer.mozilla.org/en/SpiderMonkey/Build_Documentation#Building_SpiderMonkey_tip Building SpiderMonkey Tip].

=== Fix something ===

At this point, you're ready to make your first fix.

TODO: something useless. Maybe adding a datemicrosecond function.

==== Building your changes ====

Having made the change, build the shell again.

make -C build_DBG.OBJ

==== Testing your changes ====

It builds. Hurray. Time to run the tests to check you haven't broken anything.

jit-test/jit_test.py build_DBG.OBJ/dist/bin/js
(The location of the shell has changed, it used to be build_DBG.OBJ/js)

The jit-tests are pretty quick, and should give you an idea if you've gotten something wrong. Assuming nothing goes wrong, try the ref-tests:

tests/jstests.py build_DBG.OBJ/dist/bin/js

Note that some of these tests fail depending on the timezone and locale they're run in, so if you get any errors that don't seem related to your changes, re-run the tests with a shell build without your changes applied and compare the results.

==== Benchmark your changes ====

Tests all pass. Congrats, you didn't break anything. Now, did you make it faster or slower? We benchmark using the v8 and SunSpider benchmarks. Get the benchmarks:

svn checkout http://svn.webkit.org/repository/webkit/trunk/PerformanceTests/SunSpider

And now run them:

cd SunSpider
./sunspider --shell=../build_DBG.OBJ/dist/bin/js --run=30 --suite=sunspider-0.9.1
cd ..

===== Optimized build =====

Whoops, we benchmarked the debug version. Let's make an optimized build to test instead.

mkdir build_OPT.OBJ
cd build_OPT.OBJ
../configure --disable-debug --enable-optimize
make
cd ..

Repeat the sunspider steps above, and take note of the line that looks like:

Results are located at sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js

You'll need that later.

===== Baseline version / Mercurial Queues =====

We need to time our optimized version against the baseline version. This calls for a brief introduction to mercurial queues, which used to be the way most people managed their SpiderMonkey workflow (though these days many people use native hg, native hg + evolution, or git):

hg qinit
hg qnew my_first_patch -f
hg qrefresh

This puts your current work into a patch, managed by Mercurial, symbolically called my_first_patch. To pop the patch off:

hg qpop

And we're back to our pristine version.

===== Compare =====

Build again and rerun SunSpider again. You should now have two files like:

sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js

Compare them using the compare script:

cd SunSpider
./sunspider-compare-results --shell=../build_DBG.OBJ/js --suite=sunspider-0.9.1 FILE1-withoutPatch FILE2-withPatch

=== Get a real bug ===

At this point, you've seen nearly everything you need to do hack on SpiderMonkey. So it's time to get a real bug to work on. You can get a bug on [http://www.joshmatthews.net/bugsahoy/?jseng=1&unowned=1 Bugs Ahoy].

Fix the bug, updating the bug report with your progress, and asking questions as you go (either in the bug comments, or in [irc://irc.mozilla.org/#jsapi #jsapi]). When it's done, repeat all the steps above. Then it's time to get your patch into the tree.

=== Submit a patch ===

To get the patch from mercurial, use:

hg qdiff # if you're using queues or
hg diff # if you're not

Add it to the bug as an attachment.

=== Get a review ===

Nothing gets into the tree without a review, so you'll need one. The [[JavaScript:Hackers|SpiderMonkey hackers list]] is a good place to start: if your patch changes something listed as an area of expertise for someone there, that's a good person to ask for a review.

Alternatively run <code>hg blame</code> on the files you've changed, and check who has been changing related code recently. They're likely to be good candidates. An irc bot can automate this process for a single file if you enter "/msg mrgiggles who can review something.cpp?" into your irc client.

The review will consist of comments on your changes, suggesting or requesting alternative ways to do something and asking you to make changes where needed. They might also request additional changes, for example tests. Fix what they ask, resubmit the patch to bugzilla, and ask for another review. After you repeat this step a few times, they will mark the patch as "<code>r+</code>" meaning it's now good to commit.

=== Commit ===

You can't commit to mozilla-central / mozilla-inbound until you have "level 3" access, so you'll need someone to do this for you. Try asking in [irc://irc.mozilla.org/#jsapi #jsapi], or add the <code>checkin-needed</code> keyword to the bug. After you have been contributing for a while, you can get level 3 access by [https://www.mozilla.org/hacking/commit-access-policy/ applying for it].

After committing, a large series of tests will be run to make sure you didn't break anything. You'll need to hang around to make sure you didn't break something. Check [http://tbpl.mozilla.org/?tree=Firefox the Firefox tree] for failures. Sometimes failures will be spurious: ask [irc://irc.mozilla.org/#jsapi for help] determining when this is the case, to start. (Over time you'll figure out when this is and isn't the case yourself.)

== Overview of the JS engine ==

The JS engine is a swiftly moving target. The most detailed information is available at https://developer.mozilla.org/en/SpiderMonkey. Here are some particularly interesting, mostly up-to-date resources:

=== High level overviews ===

(Outdated) http://hacks.mozilla.org/2010/03/a-quick-note-on-javascript-engine-components/

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals

=== Medium level documentation ===

jsapi.h: http://hg.mozilla.org/mozilla-central/file/tip/js/src/jsapi.h

Frequently used coding recipes and mappings from JS idioms to SpiderMonkey code: https://developer.mozilla.org/En/SpiderMonkey/JSAPI_Cookbook

=== Detailed documentation ===

Build: https://developer.mozilla.org/en/SpiderMonkey/Build_Documentation

Testing: https://developer.mozilla.org/en/SpiderMonkey/Running_Automated_JavaScript_Tests

Shell: https://developer.mozilla.org/En/SpiderMonkey/Introduction_to_the_JavaScript_shell

Function reference: https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference

== Collaboration and teamwork ==

=== Communication (in descending order of information content) ===

Nearly all communication is handled through [https://bugzilla.mozilla.org Bugzilla]. All bugs, feature requests, issues, enhancements, etc, are all referred to as bugs. No code may enter the Mozilla repository without being a patch attached to a bugzilla bug first. To follow all SpiderMonkey related bugs:

Go to [https://bugzilla.mozilla.org/userprefs.cgi?tab=email email preferences]
Watch the user general@spidermonkey.bugs

SpiderMonkey contributors generally hang out in the very active [irc://irc.mozilla.org/jsapi #jsapi IRC channel].

The [https://www.mozilla.org/about/forums/#dev-tech-js-engine-internals js-internals mailing list] is used for communicating with other SpiderMonkey hackers. (Internals as in discussing the internals of the SpiderMonkey engine. All are welcome on the list.).

Reading Planet Mozilla is the best way to keep up with the Mozilla project, which includes some SpiderMonkey related blogs:

[https://blog.mozilla.org/javascript General JavaScript blog]
[http://blog.mozilla.com/jorendorff Jason Orendorff]
[http://blog.mozilla.com/nnethercote/ Nicholas Nethercote]
[http://whereswalden.com/ Jeff Walden]
[https://itcouldbesomuchbetter.wordpress.com Jim Blandy]
[https://jandemooij.nl/ Jan de Mooij]
[https://h4writer.com/ Hannes Verschore]
[http://rfrn.org/~shu/ Shu-yu Guo]
[https://blog.benj.me/tag/mozilla.html Benjamin Bouvier]

The [https://developer.mozilla.org/en/SpiderMonkey#Community js-engine mailing list] is generally used for communicating with people who embed SpiderMonkey, such as asking questions and announcing API changes. No actual development happens on the list.

== Code considerations ==

=== Repository ===

Most active work on SpiderMonkey is done in the [http://hg.mozilla.org/mozilla-central mozilla-central] branch of the mozilla repository.

=== Coding Style ===

For many years, SpiderMonkey was written in C, and is gradually moving to C++. We still avoid many features such as run-time type information and virtual functions, but have come around to the glory of templates and namespaces relatively recently. Read the [[JavaScript:SpiderMonkey:C++ Coding Style|Coding Style]]. Do NOT read the portability guidelines, which I will not link to, since they are very out of date.

=== Workflow ===

Everything goes through bugzilla. We find a bug or have an idea, then submit it to bugzilla, then file patches to solve it. When it is solved, the patch is reviewed by team members, and is then committed to the [http://hg.mozilla.org/mozilla-central mozilla-central repository]. A link to the commit is then added as a comment to the bug.

As well as committing to [http://hg.mozilla.org/mozilla-central mozilla-central], we also have the option of committing to [http://hg.mozilla.org/integration/mozilla-inbound mozilla-inbound], which is automatically merged to mozilla-central by a Sheriff. This exempts us from watching [http://tbpl.mozilla.org tinderbox] to check for errors in our patches, and commits are automatically backed out if errors are found.

==== Sample Workflows ====

(Outdated) [http://blog.mozilla.com/nnethercote/2009/07/27/how-i-work-on-tracemonkey/ Nicholas Nethercote: How I work on Tracemonkey]

=== Policy ===

The following docs are for the Mozilla project, and differ ever so slightly from what you should do for SpiderMonkey. For example, you should find reviewers in #jsapi rather than #developers.

[http://www.mozilla.org/hacking/committer/ How to get commit access]

[https://developer.mozilla.org/en/Creating_a_patch How to make patches]

[https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch Submitting a patch]

[https://developer.mozilla.org/en/Supported_build_configurations Supported Platforms]

==== .hgrc file ====

This .hgrc file contains a lot of the wisdom distilled through the wiki:

[extensions]
mq =

[ui]
username = First Last <email@domain.tld>

[alias]
qfulldiff = diff --rev qparent:.

[defaults]
diff = -p -U 8
qdiff = -p -U 8
qnew = -U
commit = -v

[diff]
git = true
showfunc = true
unified = 8

[paths]
try = ssh://email@domain.tld@hg.mozilla.org/try/

=== Try server ===

Often, you may be a little wary of breaking things. Mozilla has a [[Build:TryServer|Try Server]] where you can send a patch, and it'll be built and tested on tons of machines, which report to [http://tbpl.mozilla.org/?tree=Try TBPL]. Although you don't have [https://www.mozilla.org/hacking/commit-access-policy/ access] to TryServer just yet, you can get someone else to push it there for you. Just attach a patch to your bug, and ask in a comment, or on [irc://irc.mozilla.org/#jsapi #jsapi]. To be able to push to try-server yourself, you will need "level 1" access, which you can [https://www.mozilla.org/hacking/commit-access-policy/ request] once you've contributed a patch or two.

=== Mercurial Queues ===

Since most of our lives revolve around patches, and we use Mercurial, nearly everybody uses Mercurial queues.

Queues are based on the idea of patch management. Each queue consists of a series of patches, applied sequentially. The aim of the game is to split potential commits into simple, bite-sized chunks which are easy to review. This also makes it simple to experiment without polluting your existing work on a bug, to spin parts off into new bugs, and to rapidly apply and unapply patches (as demonstrated in the tutorial above).

==== Enabling ====

Add the following snippet to your .hgrc file to enable MQ

[extensions]
mq =

==== Example MQ workflow ====

Clone the repository to deal with a bug:

hg clone http://hg.mozilla.org/mozilla-central

Initialize your queue:

hg qinit -c

Create a new patch, with some name:

hg qnew first_attempt

Work on the patch, try to fix the bug, test, compile, etc.

Refresh (save your work into the patch):

hg qrefresh

Repeat a few times.

Rename the patch (because your first name wasn't appliable):

hg qrename refactor_the_whatsit

Create a new patch to try a logically separate part of the same bug:

hg qnew rip_out_the_old_thing

Repeat the process a few times, until you have solved the problem. During this time, it can often be useful to go back and forth between patches:

hg qpop # unapply a patch
hg qpush # reapply a patch
hg qpop -a # unapply all patches
hg qpush -a # reapply all patches

Combine all the patches into a single patch, which you submit to bugzilla:

hg qpush -a
hg qdiff --rev qparent:. > my_wonderful_patch.patch

Commit the patches to your local patch repository, in case you make a mistake (You might do this periodically):

hg qcommit -m "Some message. Doesn't have to be good, this won't be committed to the repository, it's just for you"

Go back to the old patches and fiddle with them based on feedback:

hg qpop
hg qrefresh
etc

There are some more complex techniques that we won't go into in detail. You can enable only some patches using qguard and qselect, and you can reorder the patches by manually editing the .hg/patches/series file. But be careful!

[[Category:New Contributor Landing Page]]

JavaScript:New to SpiderMonkey

2016-10-11T15:37:36Z

Sfink: /* Baseline version / Mercurial Queues */ the sequencing of the wording was awkward

== Tutorial: your first patch ==

The first step to getting involved with SpiderMonkey is to make your first patch. This guides you through it, and at the end you should have learnt a lot of the procedures and formalisms involved in getting things done here.

We'll assume you're on a Unix-y platform, and that you know what you're doing. We'll ignore nearly all details.

=== Get the code ===

Spidermonkey development happens in the "mozilla-central" mercurial repository:

hg clone http://hg.mozilla.org/mozilla-central spidermonkey

=== Build the js shell ===

Most of the time, you'll be working with the Javascript shell, instead of the full Firefox browser. So build the shell:

cd spidermonkey/js/src
cp configure.in configure && chmod +x configure # or autoconf2.13 or autoconf-2.13
mkdir build_DBG.OBJ
cd build_DBG.OBJ
../configure --enable-debug --disable-optimize
make # or make -j8
cd ..

If you're having trouble or are missing dependencies, refer to [https://developer.mozilla.org/en/SpiderMonkey/Build_Documentation#Building_SpiderMonkey_tip Building SpiderMonkey Tip].

=== Fix something ===

At this point, you're ready to make your first fix.

TODO: something useless. Maybe adding a datemicrosecond function.

==== Building your changes ====

Having made the change, build the shell again.

make -C build_DBG.OBJ

==== Testing your changes ====

It builds. Hurray. Time to run the tests to check you haven't broken anything.

jit-test/jit_test.py build_DBG.OBJ/dist/bin/js
(The location of the shell has changed, it used to be build_DBG.OBJ/js)

The jit-tests are pretty quick, and should give you an idea if you've gotten something wrong. Assuming nothing goes wrong, try the ref-tests:

tests/jstests.py build_DBG.OBJ/dist/bin/js

Note that some of these tests fail depending on the timezone and locale they're run in, so if you get any errors that don't seem related to your changes, re-run the tests with a shell build without your changes applied and compare the results.

==== Benchmark your changes ====

Tests all pass. Congrats, you didn't break anything. Now, did you make it faster or slower? We benchmark using the v8 and SunSpider benchmarks. Get the benchmarks:

svn checkout http://svn.webkit.org/repository/webkit/trunk/PerformanceTests/SunSpider

And now run them:

cd SunSpider
./sunspider --shell=../build_DBG.OBJ/dist/bin/js --run=30 --suite=sunspider-0.9.1
cd ..

===== Optimized build =====

Whoops, we benchmarked the debug version. Let's make an optimized build to test instead.

mkdir build_OPT.OBJ
cd build_OPT.OBJ
../configure --disable-debug --enable-optimize
make
cd ..

Repeat the sunspider steps above, and take note of the line that looks like:

Results are located at sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js

You'll need that later.

===== Baseline version / Mercurial Queues =====

We need to time our optimized version against the baseline version. This calls for a brief introduction to mercurial queues, which used to be the way most people managed their SpiderMonkey workflow (though these days many people use native hg, native hg + evolution, or git):

hg qinit
hg qnew my_first_patch -f
hg qrefresh

This puts your current work into a patch, managed by Mercurial, symbolically called my_first_patch. To pop the patch off:

hg qpop

And we're back to our pristine version.

===== Compare =====

Build again and rerun SunSpider again. You should now have two files like:

sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js

Compare them using the compare script:

cd SunSpider
./sunspider-compare-results --shell=../build_DBG.OBJ/js --suite=sunspider-0.9.1 FILE1-withoutPatch FILE2-withPatch

=== Get a real bug ===

At this point, you've seen nearly everything you need to do hack on SpiderMonkey. So it's time to get a real bug to work on. You can get a bug on [http://www.joshmatthews.net/bugsahoy/?jseng=1&unowned=1 Bugs Ahoy].

Fix the bug, updating the bug report with your progress, and asking questions as you go (either in the bug comments, or in [irc://irc.mozilla.org/#jsapi #jsapi]). When it's done, repeat all the steps above. Then it's time to get your patch into the tree.

=== Submit a patch ===

To get the patch from mercurial, use:

hg qdiff # if you're using queues or
hg diff # if you're not

Add it to the bug as an attachment.

=== Get a review ===

Nothing gets into the tree without a review, so you'll need one. The [[JavaScript:Hackers|SpiderMonkey hackers list]] is a good place to start: if your patch changes something listed as an area of expertise for someone there, that's a good person to ask for a review.

Alternatively run <code>hg blame</code> on the files you've changed, and check who has been changing related code recently. They're likely to be good candidates.

The review will consist of comments on your changes, suggesting or requesting alternative ways to do something and asking you to make changes where needed. They might also request additional changes, for example tests. Fix what they ask, resubmit the patch to bugzilla, and ask for another review. After you repeat this step a few times, they're mark the patch as "<code>r+</code>" meaning it's now good to commit.

=== Commit ===

You can't commit to mozilla-central / mozilla-inbound until you have "level 3" access, so you'll need someone to do this for you. Try asking in [irc://irc.mozilla.org/#jsapi #jsapi], or add the <code>checkin-needed</code> keyword to the bug. After you have been contributing for a while, you can get level 3 access by [https://www.mozilla.org/hacking/commit-access-policy/ applying for it].

After committing, a large series of tests will be run to make sure you didn't break anything. You'll need to hang around to make sure you didn't break something. Check [http://tbpl.mozilla.org/?tree=Firefox the Firefox tree] for failures. Sometimes failures will be spurious: ask [irc://irc.mozilla.org/#jsapi for help] determining when this is the case, to start. (Over time you'll figure out when this is and isn't the case yourself.)

== Overview of the JS engine ==

The JS engine is a swiftly moving target. The most detailed information is available at https://developer.mozilla.org/en/SpiderMonkey. Here are some particularly interesting, mostly up-to-date resources:

=== High level overviews ===

(Outdated) http://hacks.mozilla.org/2010/03/a-quick-note-on-javascript-engine-components/

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals

=== Medium level documentation ===

jsapi.h: http://hg.mozilla.org/mozilla-central/file/tip/js/src/jsapi.h

Frequently used coding recipes and mappings from JS idioms to SpiderMonkey code: https://developer.mozilla.org/En/SpiderMonkey/JSAPI_Cookbook

=== Detailed documentation ===

Build: https://developer.mozilla.org/en/SpiderMonkey/Build_Documentation

Testing: https://developer.mozilla.org/en/SpiderMonkey/Running_Automated_JavaScript_Tests

Shell: https://developer.mozilla.org/En/SpiderMonkey/Introduction_to_the_JavaScript_shell

Function reference: https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference

== Collaboration and teamwork ==

=== Communication (in descending order of information content) ===

Nearly all communication is handled through [https://bugzilla.mozilla.org Bugzilla]. All bugs, feature requests, issues, enhancements, etc, are all referred to as bugs. No code may enter the Mozilla repository without being a patch attached to a bugzilla bug first. To follow all SpiderMonkey related bugs:

Go to [https://bugzilla.mozilla.org/userprefs.cgi?tab=email email preferences]
Watch the user general@spidermonkey.bugs

SpiderMonkey contributors generally hang out in the very active [irc://irc.mozilla.org/jsapi #jsapi IRC channel].

The [https://www.mozilla.org/about/forums/#dev-tech-js-engine-internals js-internals mailing list] is used for communicating with other SpiderMonkey hackers. (Internals as in discussing the internals of the SpiderMonkey engine. All are welcome on the list.).

Reading Planet Mozilla is the best way to keep up with the Mozilla project, which includes some SpiderMonkey related blogs:

[https://blog.mozilla.org/javascript General JavaScript blog]
[http://blog.mozilla.com/jorendorff Jason Orendorff]
[http://blog.mozilla.com/nnethercote/ Nicholas Nethercote]
[http://whereswalden.com/ Jeff Walden]
[https://itcouldbesomuchbetter.wordpress.com Jim Blandy]
[https://jandemooij.nl/ Jan de Mooij]
[https://h4writer.com/ Hannes Verschore]
[http://rfrn.org/~shu/ Shu-yu Guo]
[https://blog.benj.me/tag/mozilla.html Benjamin Bouvier]

The [https://developer.mozilla.org/en/SpiderMonkey#Community js-engine mailing list] is generally used for communicating with people who embed SpiderMonkey, such as asking questions and announcing API changes. No actual development happens on the list.

== Code considerations ==

=== Repository ===

Most active work on SpiderMonkey is done in the [http://hg.mozilla.org/mozilla-central mozilla-central] branch of the mozilla repository.

=== Coding Style ===

For many years, SpiderMonkey was written in C, and is gradually moving to C++. We still avoid many features such as run-time type information and virtual functions, but have come around to the glory of templates and namespaces relatively recently. Read the [[JavaScript:SpiderMonkey:C++ Coding Style|Coding Style]]. Do NOT read the portability guidelines, which I will not link to, since they are very out of date.

=== Workflow ===

Everything goes through bugzilla. We find a bug or have an idea, then submit it to bugzilla, then file patches to solve it. When it is solved, the patch is reviewed by team members, and is then committed to the [http://hg.mozilla.org/mozilla-central mozilla-central repository]. A link to the commit is then added as a comment to the bug.

As well as committing to [http://hg.mozilla.org/mozilla-central mozilla-central], we also have the option of committing to [http://hg.mozilla.org/integration/mozilla-inbound mozilla-inbound], which is automatically merged to mozilla-central by a Sheriff. This exempts us from watching [http://tbpl.mozilla.org tinderbox] to check for errors in our patches, and commits are automatically backed out if errors are found.

==== Sample Workflows ====

(Outdated) [http://blog.mozilla.com/nnethercote/2009/07/27/how-i-work-on-tracemonkey/ Nicholas Nethercote: How I work on Tracemonkey]

=== Policy ===

The following docs are for the Mozilla project, and differ ever so slightly from what you should do for SpiderMonkey. For example, you should find reviewers in #jsapi rather than #developers.

[http://www.mozilla.org/hacking/committer/ How to get commit access]

[https://developer.mozilla.org/en/Creating_a_patch How to make patches]

[https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch Submitting a patch]

[https://developer.mozilla.org/en/Supported_build_configurations Supported Platforms]

==== .hgrc file ====

This .hgrc file contains a lot of the wisdom distilled through the wiki:

[extensions]
mq =

[ui]
username = First Last <email@domain.tld>

[alias]
qfulldiff = diff --rev qparent:.

[defaults]
diff = -p -U 8
qdiff = -p -U 8
qnew = -U
commit = -v

[diff]
git = true
showfunc = true
unified = 8

[paths]
try = ssh://email@domain.tld@hg.mozilla.org/try/

=== Try server ===

Often, you may be a little wary of breaking things. Mozilla has a [[Build:TryServer|Try Server]] where you can send a patch, and it'll be built and tested on tons of machines, which report to [http://tbpl.mozilla.org/?tree=Try TBPL]. Although you don't have [https://www.mozilla.org/hacking/commit-access-policy/ access] to TryServer just yet, you can get someone else to push it there for you. Just attach a patch to your bug, and ask in a comment, or on [irc://irc.mozilla.org/#jsapi #jsapi]. To be able to push to try-server yourself, you will need "level 1" access, which you can [https://www.mozilla.org/hacking/commit-access-policy/ request] once you've contributed a patch or two.

=== Mercurial Queues ===

Since most of our lives revolve around patches, and we use Mercurial, nearly everybody uses Mercurial queues.

Queues are based on the idea of patch management. Each queue consists of a series of patches, applied sequentially. The aim of the game is to split potential commits into simple, bite-sized chunks which are easy to review. This also makes it simple to experiment without polluting your existing work on a bug, to spin parts off into new bugs, and to rapidly apply and unapply patches (as demonstrated in the tutorial above).

==== Enabling ====

Add the following snippet to your .hgrc file to enable MQ

[extensions]
mq =

==== Example MQ workflow ====

Clone the repository to deal with a bug:

hg clone http://hg.mozilla.org/mozilla-central

Initialize your queue:

hg qinit -c

Create a new patch, with some name:

hg qnew first_attempt

Work on the patch, try to fix the bug, test, compile, etc.

Refresh (save your work into the patch):

hg qrefresh

Repeat a few times.

Rename the patch (because your first name wasn't appliable):

hg qrename refactor_the_whatsit

Create a new patch to try a logically separate part of the same bug:

hg qnew rip_out_the_old_thing

Repeat the process a few times, until you have solved the problem. During this time, it can often be useful to go back and forth between patches:

hg qpop # unapply a patch
hg qpush # reapply a patch
hg qpop -a # unapply all patches
hg qpush -a # reapply all patches

Combine all the patches into a single patch, which you submit to bugzilla:

hg qpush -a
hg qdiff --rev qparent:. > my_wonderful_patch.patch

Commit the patches to your local patch repository, in case you make a mistake (You might do this periodically):

hg qcommit -m "Some message. Doesn't have to be good, this won't be committed to the repository, it's just for you"

Go back to the old patches and fiddle with them based on feedback:

hg qpop
hg qrefresh
etc

There are some more complex techniques that we won't go into in detail. You can enable only some patches using qguard and qselect, and you can reorder the patches by manually editing the .hg/patches/series file. But be careful!

[[Category:New Contributor Landing Page]]

JavaScript:New to SpiderMonkey

2016-10-11T15:36:49Z

Sfink: /* Baseline version / Mercurial Queues */ mq is kinda deprecated

== Tutorial: your first patch ==

The first step to getting involved with SpiderMonkey is to make your first patch. This guides you through it, and at the end you should have learnt a lot of the procedures and formalisms involved in getting things done here.

We'll assume you're on a Unix-y platform, and that you know what you're doing. We'll ignore nearly all details.

=== Get the code ===

Spidermonkey development happens in the "mozilla-central" mercurial repository:

hg clone http://hg.mozilla.org/mozilla-central spidermonkey

=== Build the js shell ===

Most of the time, you'll be working with the Javascript shell, instead of the full Firefox browser. So build the shell:

cd spidermonkey/js/src
cp configure.in configure && chmod +x configure # or autoconf2.13 or autoconf-2.13
mkdir build_DBG.OBJ
cd build_DBG.OBJ
../configure --enable-debug --disable-optimize
make # or make -j8
cd ..

If you're having trouble or are missing dependencies, refer to [https://developer.mozilla.org/en/SpiderMonkey/Build_Documentation#Building_SpiderMonkey_tip Building SpiderMonkey Tip].

=== Fix something ===

At this point, you're ready to make your first fix.

TODO: something useless. Maybe adding a datemicrosecond function.

==== Building your changes ====

Having made the change, build the shell again.

make -C build_DBG.OBJ

==== Testing your changes ====

It builds. Hurray. Time to run the tests to check you haven't broken anything.

jit-test/jit_test.py build_DBG.OBJ/dist/bin/js
(The location of the shell has changed, it used to be build_DBG.OBJ/js)

The jit-tests are pretty quick, and should give you an idea if you've gotten something wrong. Assuming nothing goes wrong, try the ref-tests:

tests/jstests.py build_DBG.OBJ/dist/bin/js

Note that some of these tests fail depending on the timezone and locale they're run in, so if you get any errors that don't seem related to your changes, re-run the tests with a shell build without your changes applied and compare the results.

==== Benchmark your changes ====

Tests all pass. Congrats, you didn't break anything. Now, did you make it faster or slower? We benchmark using the v8 and SunSpider benchmarks. Get the benchmarks:

svn checkout http://svn.webkit.org/repository/webkit/trunk/PerformanceTests/SunSpider

And now run them:

cd SunSpider
./sunspider --shell=../build_DBG.OBJ/dist/bin/js --run=30 --suite=sunspider-0.9.1
cd ..

===== Optimized build =====

Whoops, we benchmarked the debug version. Let's make an optimized build to test instead.

mkdir build_OPT.OBJ
cd build_OPT.OBJ
../configure --disable-debug --enable-optimize
make
cd ..

Repeat the sunspider steps above, and take note of the line that looks like:

Results are located at sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js

You'll need that later.

===== Baseline version / Mercurial Queues =====

We need to time our optimized version against the baseline version. This calls for a brief introduction to mercurial queues, which used to be the way most people managed their SpiderMonkey workflow, though these days people use native hg, native hg + evolution, or git:

hg qinit
hg qnew my_first_patch -f
hg qrefresh

This puts your current work into a patch, managed by Mercurial, symbolically called my_first_patch. To pop the patch off:

hg qpop

And we're back to our pristine version.

===== Compare =====

Build again and rerun SunSpider again. You should now have two files like:

sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js

Compare them using the compare script:

cd SunSpider
./sunspider-compare-results --shell=../build_DBG.OBJ/js --suite=sunspider-0.9.1 FILE1-withoutPatch FILE2-withPatch

=== Get a real bug ===

At this point, you've seen nearly everything you need to do hack on SpiderMonkey. So it's time to get a real bug to work on. You can get a bug on [http://www.joshmatthews.net/bugsahoy/?jseng=1&unowned=1 Bugs Ahoy].

Fix the bug, updating the bug report with your progress, and asking questions as you go (either in the bug comments, or in [irc://irc.mozilla.org/#jsapi #jsapi]). When it's done, repeat all the steps above. Then it's time to get your patch into the tree.

=== Submit a patch ===

To get the patch from mercurial, use:

hg qdiff # if you're using queues or
hg diff # if you're not

Add it to the bug as an attachment.

=== Get a review ===

Nothing gets into the tree without a review, so you'll need one. The [[JavaScript:Hackers|SpiderMonkey hackers list]] is a good place to start: if your patch changes something listed as an area of expertise for someone there, that's a good person to ask for a review.

Alternatively run <code>hg blame</code> on the files you've changed, and check who has been changing related code recently. They're likely to be good candidates.

The review will consist of comments on your changes, suggesting or requesting alternative ways to do something and asking you to make changes where needed. They might also request additional changes, for example tests. Fix what they ask, resubmit the patch to bugzilla, and ask for another review. After you repeat this step a few times, they're mark the patch as "<code>r+</code>" meaning it's now good to commit.

=== Commit ===

You can't commit to mozilla-central / mozilla-inbound until you have "level 3" access, so you'll need someone to do this for you. Try asking in [irc://irc.mozilla.org/#jsapi #jsapi], or add the <code>checkin-needed</code> keyword to the bug. After you have been contributing for a while, you can get level 3 access by [https://www.mozilla.org/hacking/commit-access-policy/ applying for it].

After committing, a large series of tests will be run to make sure you didn't break anything. You'll need to hang around to make sure you didn't break something. Check [http://tbpl.mozilla.org/?tree=Firefox the Firefox tree] for failures. Sometimes failures will be spurious: ask [irc://irc.mozilla.org/#jsapi for help] determining when this is the case, to start. (Over time you'll figure out when this is and isn't the case yourself.)

== Overview of the JS engine ==

The JS engine is a swiftly moving target. The most detailed information is available at https://developer.mozilla.org/en/SpiderMonkey. Here are some particularly interesting, mostly up-to-date resources:

=== High level overviews ===

(Outdated) http://hacks.mozilla.org/2010/03/a-quick-note-on-javascript-engine-components/

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals

=== Medium level documentation ===

jsapi.h: http://hg.mozilla.org/mozilla-central/file/tip/js/src/jsapi.h

Frequently used coding recipes and mappings from JS idioms to SpiderMonkey code: https://developer.mozilla.org/En/SpiderMonkey/JSAPI_Cookbook

=== Detailed documentation ===

Build: https://developer.mozilla.org/en/SpiderMonkey/Build_Documentation

Testing: https://developer.mozilla.org/en/SpiderMonkey/Running_Automated_JavaScript_Tests

Shell: https://developer.mozilla.org/En/SpiderMonkey/Introduction_to_the_JavaScript_shell

Function reference: https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference

== Collaboration and teamwork ==

=== Communication (in descending order of information content) ===

Nearly all communication is handled through [https://bugzilla.mozilla.org Bugzilla]. All bugs, feature requests, issues, enhancements, etc, are all referred to as bugs. No code may enter the Mozilla repository without being a patch attached to a bugzilla bug first. To follow all SpiderMonkey related bugs:

Go to [https://bugzilla.mozilla.org/userprefs.cgi?tab=email email preferences]
Watch the user general@spidermonkey.bugs

SpiderMonkey contributors generally hang out in the very active [irc://irc.mozilla.org/jsapi #jsapi IRC channel].

The [https://www.mozilla.org/about/forums/#dev-tech-js-engine-internals js-internals mailing list] is used for communicating with other SpiderMonkey hackers. (Internals as in discussing the internals of the SpiderMonkey engine. All are welcome on the list.).

Reading Planet Mozilla is the best way to keep up with the Mozilla project, which includes some SpiderMonkey related blogs:

[https://blog.mozilla.org/javascript General JavaScript blog]
[http://blog.mozilla.com/jorendorff Jason Orendorff]
[http://blog.mozilla.com/nnethercote/ Nicholas Nethercote]
[http://whereswalden.com/ Jeff Walden]
[https://itcouldbesomuchbetter.wordpress.com Jim Blandy]
[https://jandemooij.nl/ Jan de Mooij]
[https://h4writer.com/ Hannes Verschore]
[http://rfrn.org/~shu/ Shu-yu Guo]
[https://blog.benj.me/tag/mozilla.html Benjamin Bouvier]

The [https://developer.mozilla.org/en/SpiderMonkey#Community js-engine mailing list] is generally used for communicating with people who embed SpiderMonkey, such as asking questions and announcing API changes. No actual development happens on the list.

== Code considerations ==

=== Repository ===

Most active work on SpiderMonkey is done in the [http://hg.mozilla.org/mozilla-central mozilla-central] branch of the mozilla repository.

=== Coding Style ===

For many years, SpiderMonkey was written in C, and is gradually moving to C++. We still avoid many features such as run-time type information and virtual functions, but have come around to the glory of templates and namespaces relatively recently. Read the [[JavaScript:SpiderMonkey:C++ Coding Style|Coding Style]]. Do NOT read the portability guidelines, which I will not link to, since they are very out of date.

=== Workflow ===

Everything goes through bugzilla. We find a bug or have an idea, then submit it to bugzilla, then file patches to solve it. When it is solved, the patch is reviewed by team members, and is then committed to the [http://hg.mozilla.org/mozilla-central mozilla-central repository]. A link to the commit is then added as a comment to the bug.

As well as committing to [http://hg.mozilla.org/mozilla-central mozilla-central], we also have the option of committing to [http://hg.mozilla.org/integration/mozilla-inbound mozilla-inbound], which is automatically merged to mozilla-central by a Sheriff. This exempts us from watching [http://tbpl.mozilla.org tinderbox] to check for errors in our patches, and commits are automatically backed out if errors are found.

==== Sample Workflows ====

(Outdated) [http://blog.mozilla.com/nnethercote/2009/07/27/how-i-work-on-tracemonkey/ Nicholas Nethercote: How I work on Tracemonkey]

=== Policy ===

The following docs are for the Mozilla project, and differ ever so slightly from what you should do for SpiderMonkey. For example, you should find reviewers in #jsapi rather than #developers.

[http://www.mozilla.org/hacking/committer/ How to get commit access]

[https://developer.mozilla.org/en/Creating_a_patch How to make patches]

[https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch Submitting a patch]

[https://developer.mozilla.org/en/Supported_build_configurations Supported Platforms]

==== .hgrc file ====

This .hgrc file contains a lot of the wisdom distilled through the wiki:

[extensions]
mq =

[ui]
username = First Last <email@domain.tld>

[alias]
qfulldiff = diff --rev qparent:.

[defaults]
diff = -p -U 8
qdiff = -p -U 8
qnew = -U
commit = -v

[diff]
git = true
showfunc = true
unified = 8

[paths]
try = ssh://email@domain.tld@hg.mozilla.org/try/

=== Try server ===

Often, you may be a little wary of breaking things. Mozilla has a [[Build:TryServer|Try Server]] where you can send a patch, and it'll be built and tested on tons of machines, which report to [http://tbpl.mozilla.org/?tree=Try TBPL]. Although you don't have [https://www.mozilla.org/hacking/commit-access-policy/ access] to TryServer just yet, you can get someone else to push it there for you. Just attach a patch to your bug, and ask in a comment, or on [irc://irc.mozilla.org/#jsapi #jsapi]. To be able to push to try-server yourself, you will need "level 1" access, which you can [https://www.mozilla.org/hacking/commit-access-policy/ request] once you've contributed a patch or two.

=== Mercurial Queues ===

Since most of our lives revolve around patches, and we use Mercurial, nearly everybody uses Mercurial queues.

Queues are based on the idea of patch management. Each queue consists of a series of patches, applied sequentially. The aim of the game is to split potential commits into simple, bite-sized chunks which are easy to review. This also makes it simple to experiment without polluting your existing work on a bug, to spin parts off into new bugs, and to rapidly apply and unapply patches (as demonstrated in the tutorial above).

==== Enabling ====

Add the following snippet to your .hgrc file to enable MQ

[extensions]
mq =

==== Example MQ workflow ====

Clone the repository to deal with a bug:

hg clone http://hg.mozilla.org/mozilla-central

Initialize your queue:

hg qinit -c

Create a new patch, with some name:

hg qnew first_attempt

Work on the patch, try to fix the bug, test, compile, etc.

Refresh (save your work into the patch):

hg qrefresh

Repeat a few times.

Rename the patch (because your first name wasn't appliable):

hg qrename refactor_the_whatsit

Create a new patch to try a logically separate part of the same bug:

hg qnew rip_out_the_old_thing

Repeat the process a few times, until you have solved the problem. During this time, it can often be useful to go back and forth between patches:

hg qpop # unapply a patch
hg qpush # reapply a patch
hg qpop -a # unapply all patches
hg qpush -a # reapply all patches

Combine all the patches into a single patch, which you submit to bugzilla:

hg qpush -a
hg qdiff --rev qparent:. > my_wonderful_patch.patch

Commit the patches to your local patch repository, in case you make a mistake (You might do this periodically):

hg qcommit -m "Some message. Doesn't have to be good, this won't be committed to the repository, it's just for you"

Go back to the old patches and fiddle with them based on feedback:

hg qpop
hg qrefresh
etc

There are some more complex techniques that we won't go into in detail. You can enable only some patches using qguard and qselect, and you can reorder the patches by manually editing the .hg/patches/series file. But be careful!

[[Category:New Contributor Landing Page]]

JavaScript:New to SpiderMonkey

2016-10-11T15:34:44Z

Sfink: /* Build the js shell */ configure.in isn't really an autoconf input script anymore; it will invoke autoconf on the real stuff for you. Prefer a command that works regardless of local naming.

== Tutorial: your first patch ==

The first step to getting involved with SpiderMonkey is to make your first patch. This guides you through it, and at the end you should have learnt a lot of the procedures and formalisms involved in getting things done here.

We'll assume you're on a Unix-y platform, and that you know what you're doing. We'll ignore nearly all details.

=== Get the code ===

Spidermonkey development happens in the "mozilla-central" mercurial repository:

hg clone http://hg.mozilla.org/mozilla-central spidermonkey

=== Build the js shell ===

Most of the time, you'll be working with the Javascript shell, instead of the full Firefox browser. So build the shell:

cd spidermonkey/js/src
cp configure.in configure && chmod +x configure # or autoconf2.13 or autoconf-2.13
mkdir build_DBG.OBJ
cd build_DBG.OBJ
../configure --enable-debug --disable-optimize
make # or make -j8
cd ..

If you're having trouble or are missing dependencies, refer to [https://developer.mozilla.org/en/SpiderMonkey/Build_Documentation#Building_SpiderMonkey_tip Building SpiderMonkey Tip].

=== Fix something ===

At this point, you're ready to make your first fix.

TODO: something useless. Maybe adding a datemicrosecond function.

==== Building your changes ====

Having made the change, build the shell again.

make -C build_DBG.OBJ

==== Testing your changes ====

It builds. Hurray. Time to run the tests to check you haven't broken anything.

jit-test/jit_test.py build_DBG.OBJ/dist/bin/js
(The location of the shell has changed, it used to be build_DBG.OBJ/js)

The jit-tests are pretty quick, and should give you an idea if you've gotten something wrong. Assuming nothing goes wrong, try the ref-tests:

tests/jstests.py build_DBG.OBJ/dist/bin/js

Note that some of these tests fail depending on the timezone and locale they're run in, so if you get any errors that don't seem related to your changes, re-run the tests with a shell build without your changes applied and compare the results.

==== Benchmark your changes ====

Tests all pass. Congrats, you didn't break anything. Now, did you make it faster or slower? We benchmark using the v8 and SunSpider benchmarks. Get the benchmarks:

svn checkout http://svn.webkit.org/repository/webkit/trunk/PerformanceTests/SunSpider

And now run them:

cd SunSpider
./sunspider --shell=../build_DBG.OBJ/dist/bin/js --run=30 --suite=sunspider-0.9.1
cd ..

===== Optimized build =====

Whoops, we benchmarked the debug version. Let's make an optimized build to test instead.

mkdir build_OPT.OBJ
cd build_OPT.OBJ
../configure --disable-debug --enable-optimize
make
cd ..

Repeat the sunspider steps above, and take note of the line that looks like:

Results are located at sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js

You'll need that later.

===== Baseline version / Mercurial Queues =====

We need to time our optimized version against the baseline version. This calls for a brief introduction to mercurial queues, which most people think is a pretty good way of managing their SpiderMonkey workflow:

hg qinit
hg qnew my_first_patch -f
hg qrefresh

This puts your current work into a patch, managed by Mercurial, symbolically called my_first_patch. To pop the patch off:

hg qpop

And we're back to our pristine version.

===== Compare =====

Build again and rerun SunSpider again. You should now have two files like:

sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js

Compare them using the compare script:

cd SunSpider
./sunspider-compare-results --shell=../build_DBG.OBJ/js --suite=sunspider-0.9.1 FILE1-withoutPatch FILE2-withPatch

=== Get a real bug ===

At this point, you've seen nearly everything you need to do hack on SpiderMonkey. So it's time to get a real bug to work on. You can get a bug on [http://www.joshmatthews.net/bugsahoy/?jseng=1&unowned=1 Bugs Ahoy].

Fix the bug, updating the bug report with your progress, and asking questions as you go (either in the bug comments, or in [irc://irc.mozilla.org/#jsapi #jsapi]). When it's done, repeat all the steps above. Then it's time to get your patch into the tree.

=== Submit a patch ===

To get the patch from mercurial, use:

hg qdiff # if you're using queues or
hg diff # if you're not

Add it to the bug as an attachment.

=== Get a review ===

Nothing gets into the tree without a review, so you'll need one. The [[JavaScript:Hackers|SpiderMonkey hackers list]] is a good place to start: if your patch changes something listed as an area of expertise for someone there, that's a good person to ask for a review.

Alternatively run <code>hg blame</code> on the files you've changed, and check who has been changing related code recently. They're likely to be good candidates.

The review will consist of comments on your changes, suggesting or requesting alternative ways to do something and asking you to make changes where needed. They might also request additional changes, for example tests. Fix what they ask, resubmit the patch to bugzilla, and ask for another review. After you repeat this step a few times, they're mark the patch as "<code>r+</code>" meaning it's now good to commit.

=== Commit ===

You can't commit to mozilla-central / mozilla-inbound until you have "level 3" access, so you'll need someone to do this for you. Try asking in [irc://irc.mozilla.org/#jsapi #jsapi], or add the <code>checkin-needed</code> keyword to the bug. After you have been contributing for a while, you can get level 3 access by [https://www.mozilla.org/hacking/commit-access-policy/ applying for it].

After committing, a large series of tests will be run to make sure you didn't break anything. You'll need to hang around to make sure you didn't break something. Check [http://tbpl.mozilla.org/?tree=Firefox the Firefox tree] for failures. Sometimes failures will be spurious: ask [irc://irc.mozilla.org/#jsapi for help] determining when this is the case, to start. (Over time you'll figure out when this is and isn't the case yourself.)

== Overview of the JS engine ==

The JS engine is a swiftly moving target. The most detailed information is available at https://developer.mozilla.org/en/SpiderMonkey. Here are some particularly interesting, mostly up-to-date resources:

=== High level overviews ===

(Outdated) http://hacks.mozilla.org/2010/03/a-quick-note-on-javascript-engine-components/

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals

=== Medium level documentation ===

jsapi.h: http://hg.mozilla.org/mozilla-central/file/tip/js/src/jsapi.h

Frequently used coding recipes and mappings from JS idioms to SpiderMonkey code: https://developer.mozilla.org/En/SpiderMonkey/JSAPI_Cookbook

=== Detailed documentation ===

Build: https://developer.mozilla.org/en/SpiderMonkey/Build_Documentation

Testing: https://developer.mozilla.org/en/SpiderMonkey/Running_Automated_JavaScript_Tests

Shell: https://developer.mozilla.org/En/SpiderMonkey/Introduction_to_the_JavaScript_shell

Function reference: https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference

== Collaboration and teamwork ==

=== Communication (in descending order of information content) ===

Nearly all communication is handled through [https://bugzilla.mozilla.org Bugzilla]. All bugs, feature requests, issues, enhancements, etc, are all referred to as bugs. No code may enter the Mozilla repository without being a patch attached to a bugzilla bug first. To follow all SpiderMonkey related bugs:

Go to [https://bugzilla.mozilla.org/userprefs.cgi?tab=email email preferences]
Watch the user general@spidermonkey.bugs

SpiderMonkey contributors generally hang out in the very active [irc://irc.mozilla.org/jsapi #jsapi IRC channel].

The [https://www.mozilla.org/about/forums/#dev-tech-js-engine-internals js-internals mailing list] is used for communicating with other SpiderMonkey hackers. (Internals as in discussing the internals of the SpiderMonkey engine. All are welcome on the list.).

Reading Planet Mozilla is the best way to keep up with the Mozilla project, which includes some SpiderMonkey related blogs:

[https://blog.mozilla.org/javascript General JavaScript blog]
[http://blog.mozilla.com/jorendorff Jason Orendorff]
[http://blog.mozilla.com/nnethercote/ Nicholas Nethercote]
[http://whereswalden.com/ Jeff Walden]
[https://itcouldbesomuchbetter.wordpress.com Jim Blandy]
[https://jandemooij.nl/ Jan de Mooij]
[https://h4writer.com/ Hannes Verschore]
[http://rfrn.org/~shu/ Shu-yu Guo]
[https://blog.benj.me/tag/mozilla.html Benjamin Bouvier]

The [https://developer.mozilla.org/en/SpiderMonkey#Community js-engine mailing list] is generally used for communicating with people who embed SpiderMonkey, such as asking questions and announcing API changes. No actual development happens on the list.

== Code considerations ==

=== Repository ===

Most active work on SpiderMonkey is done in the [http://hg.mozilla.org/mozilla-central mozilla-central] branch of the mozilla repository.

=== Coding Style ===

For many years, SpiderMonkey was written in C, and is gradually moving to C++. We still avoid many features such as run-time type information and virtual functions, but have come around to the glory of templates and namespaces relatively recently. Read the [[JavaScript:SpiderMonkey:C++ Coding Style|Coding Style]]. Do NOT read the portability guidelines, which I will not link to, since they are very out of date.

=== Workflow ===

Everything goes through bugzilla. We find a bug or have an idea, then submit it to bugzilla, then file patches to solve it. When it is solved, the patch is reviewed by team members, and is then committed to the [http://hg.mozilla.org/mozilla-central mozilla-central repository]. A link to the commit is then added as a comment to the bug.

As well as committing to [http://hg.mozilla.org/mozilla-central mozilla-central], we also have the option of committing to [http://hg.mozilla.org/integration/mozilla-inbound mozilla-inbound], which is automatically merged to mozilla-central by a Sheriff. This exempts us from watching [http://tbpl.mozilla.org tinderbox] to check for errors in our patches, and commits are automatically backed out if errors are found.

==== Sample Workflows ====

(Outdated) [http://blog.mozilla.com/nnethercote/2009/07/27/how-i-work-on-tracemonkey/ Nicholas Nethercote: How I work on Tracemonkey]

=== Policy ===

The following docs are for the Mozilla project, and differ ever so slightly from what you should do for SpiderMonkey. For example, you should find reviewers in #jsapi rather than #developers.

[http://www.mozilla.org/hacking/committer/ How to get commit access]

[https://developer.mozilla.org/en/Creating_a_patch How to make patches]

[https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch Submitting a patch]

[https://developer.mozilla.org/en/Supported_build_configurations Supported Platforms]

==== .hgrc file ====

This .hgrc file contains a lot of the wisdom distilled through the wiki:

[extensions]
mq =

[ui]
username = First Last <email@domain.tld>

[alias]
qfulldiff = diff --rev qparent:.

[defaults]
diff = -p -U 8
qdiff = -p -U 8
qnew = -U
commit = -v

[diff]
git = true
showfunc = true
unified = 8

[paths]
try = ssh://email@domain.tld@hg.mozilla.org/try/

=== Try server ===

Often, you may be a little wary of breaking things. Mozilla has a [[Build:TryServer|Try Server]] where you can send a patch, and it'll be built and tested on tons of machines, which report to [http://tbpl.mozilla.org/?tree=Try TBPL]. Although you don't have [https://www.mozilla.org/hacking/commit-access-policy/ access] to TryServer just yet, you can get someone else to push it there for you. Just attach a patch to your bug, and ask in a comment, or on [irc://irc.mozilla.org/#jsapi #jsapi]. To be able to push to try-server yourself, you will need "level 1" access, which you can [https://www.mozilla.org/hacking/commit-access-policy/ request] once you've contributed a patch or two.

=== Mercurial Queues ===

Since most of our lives revolve around patches, and we use Mercurial, nearly everybody uses Mercurial queues.

Queues are based on the idea of patch management. Each queue consists of a series of patches, applied sequentially. The aim of the game is to split potential commits into simple, bite-sized chunks which are easy to review. This also makes it simple to experiment without polluting your existing work on a bug, to spin parts off into new bugs, and to rapidly apply and unapply patches (as demonstrated in the tutorial above).

==== Enabling ====

Add the following snippet to your .hgrc file to enable MQ

[extensions]
mq =

==== Example MQ workflow ====

Clone the repository to deal with a bug:

hg clone http://hg.mozilla.org/mozilla-central

Initialize your queue:

hg qinit -c

Create a new patch, with some name:

hg qnew first_attempt

Work on the patch, try to fix the bug, test, compile, etc.

Refresh (save your work into the patch):

hg qrefresh

Repeat a few times.

Rename the patch (because your first name wasn't appliable):

hg qrename refactor_the_whatsit

Create a new patch to try a logically separate part of the same bug:

hg qnew rip_out_the_old_thing

Repeat the process a few times, until you have solved the problem. During this time, it can often be useful to go back and forth between patches:

hg qpop # unapply a patch
hg qpush # reapply a patch
hg qpop -a # unapply all patches
hg qpush -a # reapply all patches

Combine all the patches into a single patch, which you submit to bugzilla:

hg qpush -a
hg qdiff --rev qparent:. > my_wonderful_patch.patch

Commit the patches to your local patch repository, in case you make a mistake (You might do this periodically):

hg qcommit -m "Some message. Doesn't have to be good, this won't be committed to the repository, it's just for you"

Go back to the old patches and fiddle with them based on feedback:

hg qpop
hg qrefresh
etc

There are some more complex techniques that we won't go into in detail. You can enable only some patches using qguard and qselect, and you can reorder the patches by manually editing the .hg/patches/series file. But be careful!

[[Category:New Contributor Landing Page]]

Benchmarking advice

2016-08-16T17:06:47Z

Sfink: maybe an interwiki link?

#REDIRECT [[mdn:docs/Mozilla/Benchmarking]]

Benchmarking advice

2016-08-16T17:03:14Z

Sfink: looks like you cannot redirect to an external page

See https://developer.mozilla.org/en-US/docs/Mozilla/Benchmarking

Benchmarking advice

2016-08-16T16:29:17Z

Sfink: maybe?

#REDIRECT [https://developer.mozilla.org/en-US/docs/Mozilla/Benchmarking]

Benchmarking advice

2016-08-16T16:27:21Z

Sfink: fix redir?

#REDIRECT [[https://developer.mozilla.org/en-US/docs/Mozilla/Benchmarking]]

Benchmarking advice

2016-08-16T16:23:57Z

Sfink: redirect to mdn

#REDIRECT https://developer.mozilla.org/en-US/docs/Mozilla/Benchmarking

Benchmarking advice

2016-08-16T01:06:36Z

Sfink: Created page with "= Debug Builds = Debug builds (--enable-debug) and non-optimized builds (--disable-optimize) are '''much''' slower. Any performance metrics gathered by such builds are largel..."

= Debug Builds =

Debug builds (--enable-debug) and non-optimized builds (--disable-optimize) are '''much''' slower. Any performance metrics gathered by such builds are largely unrelated to the what the performance a release browser would be.

= Poisoning =

Many Firefox builds have a diagnostic tool that causes crashes to happen sooner and produce much more actionable information, but also slow down regular usage substantially. In particular, "GC poisoning" is used in all debug builds, and in optimized nightly builds (but not opt developer edition or beta builds). The poisoning can be disabled by setting the environment variable

JSGC_DISABLE_POISONING=1

before starting the browser.

User:Sfink

2016-08-16T00:58:35Z

Sfink: /* "My" Pages */

Where I'm putting stuff:

* ''Things that are generally useful'': just throw them into their appropriate place on the wiki, of course. Then agonize over whether they should be on MDC instead.
* ''Rough stuff that nevertheless may contain information useful to others'': use a "sfink/" prefix, so that they show up in searches but are clearly associated with a user (me) and not taken too seriously.
* ''Notes for myself that are unlikely to be useful to anyone else'': use the "User" namespace, specifically the prefix "User:sfink/" to prevent it from showing up in a search unless someone specifically asks to see user pages.

== "My" Pages ==

From newest to oldest, roughly.

Generally useful, maybe:

* [[Benchmarking advice]]
* [[Measuring GC performance]]
* [[Managing GC-visible resources]] - best name I came up with, and I don't like it
* [[sfink/Moving GC]]
* [[sfink/Static Rooting Analysis]]
* [[sfink/Draft - GC Pointer Handling]]
* [[sfink/JS Stack Walking]]
* [[sfink/Memory Ideas]]
* [[Multiple Project Repositories]]
* [[Using SlowCalls]]
* [[Using XPerf]]
* [[sfink/Contexts and Compartments]]
* [[sfink/Thought Experiment - One Minute Builds]] - shouldn't really have a sfink/ prefix, but I couldn't think of a good title
* [[mrgiggles]] - IRC bot

Generally useless, probably:

* [[AllHands2011/tbplPlanning]]
* [[sfink/JS Profiling-Related APIs]] - attempting to make some sense of the various probes/hooks/engines
* [[sfink/Performance Thoughts]] - disorganized notes on performance
* [[User:sfink/Working On]] - obsolete-on-arrival page listing what I'm working on
* [[sfink/Laptop Setup]] - notes on configuring my laptop with Fedora Linux
* [[sfink/Building Mozilla]] - notes on compiling the tree
* [[sfink/Projects]]

== Useful/Relevant Links ==

* [[JavaScript]]
* [[Performance:Home Page]]
* [[sfink/Useful Notes]] - Stuff gathered from email, web, etc. that could be useful to others as well

{{VerifiedUser}}

Javascript:Hazard Builds

2016-06-28T20:42:06Z

Sfink: /* Static Analysis for Rooting Hazards */ put useful stuff at top

== Static Analysis for Rooting Hazards ==

Treeherder can run two static analysis builds: the full browser (linux64-haz), just the JS shell (linux64-shell-haz). They show up on treeherder as '''H''' and '''SM(H)'''.

=== Diagnosing a hazard failure ===

Click on the '''H''' build link, select the "Job details" pane on the bottom right, follow the "Inspect Task" link, and download the "public/build/hazards.txt.gz" file.

Example snippet:

<pre>
Function 'jsopcode.cpp:uint8 DecompileExpressionFromStack(JSContext*, int32, int32, class JS::Handle<JS::Value>, int8**)' has unrooted 'ed' of type 'ExpressionDecompiler' live across GC call 'uint8 ExpressionDecompiler::decompilePC(uint8*)' at js/src/jsopcode.cpp:1866
js/src/jsopcode.cpp:1866: Assume(74,75, !__temp_23*, true)
js/src/jsopcode.cpp:1867: Assign(75,76, return := 0)
js/src/jsopcode.cpp:1867: Call(76,77, ed.~ExpressionDecompiler())
GC Function: uint8 ExpressionDecompiler::decompilePC(uint8*)
JSString* js::ValueToSource(JSContext*, class JS::Handle<JS::Value>)
uint8 js::Invoke(JSContext*, JS::Value*, JS::Value*, uint32, JS::Value*, class JS::MutableHandle<JS::Value>)
uint8 js::Invoke(JSContext*, JS::CallArgs, uint32)
JSScript* JSFunction::getOrCreateScript(JSContext*)
uint8 JSFunction::createScriptForLazilyInterpretedFunction(JSContext*, class JS::Handle<JSFunction*>)
uint8 JSRuntime::cloneSelfHostedFunctionScript(JSContext*, class JS::Handle<js::PropertyName*>, class JS::Handle<JSFunction*>)
JSScript* js::CloneScript(JSContext*, class JS::Handle<JSObject*>, class JS::Handle<JSFunction*>, const class JS::Handle<JSScript*>, uint32)
JSObject* js::CloneStaticBlockObject(JSContext*, class JS::Handle<JSObject*>, class JS::Handle<js::StaticBlockObject*>)
js::StaticBlockObject* js::StaticBlockObject::create(js::ExclusiveContext*)
js::Shape* js::EmptyShape::getInitialShape(js::ExclusiveContext*, js::Class*, js::TaggedProto, JSObject*, JSObject*, uint32, uint32)
js::Shape* js::EmptyShape::getInitialShape(js::ExclusiveContext*, js::Class*, js::TaggedProto, JSObject*, JSObject*, uint64, uint32)
js::UnownedBaseShape* js::BaseShape::getUnowned(js::ExclusiveContext*, js::StackBaseShape*)
js::BaseShape* js_NewGCBaseShape(js::ThreadSafeContext*) [with js::AllowGC allowGC = (js::AllowGC)1u]
js::BaseShape* js::gc::NewGCThing(js::ThreadSafeContext*, uint32, uint64, uint32) [with T = js::BaseShape; js::AllowGC allowGC = (js::AllowGC)1u; size_t = long unsigned int]
void js::gc::RunDebugGC(JSContext*)
void js::MinorGC(JSRuntime*, uint32)
GC
</pre>

This means that a rooting hazard was discovered at js/src/jsopcode.cpp line 1866, in the function DecompileExpressionFromStack (it is prefixed with the filename because it's a static function.) The problem is that they're an unrooted variable 'ed' that holds an ExpressionDecompiler live across a call to decompilePC. "Live" means that the variable is used after the call to decompilePC returns. decompilePC may trigger a GC according to the static call stack given starting from the line beginning with "GC Function:". The hazard itself has some barely comprehensible Assume(...) and Call(...) gibberish that describes the exact path of the variable into the function call. That stuff is rarely useful -- usually, you'll only need to look at it if it's complaining about a temporary and you want to know where the temporary came from. The type 'ExpressionDecompiler' is believed to hold pointers to GC-controlled objects of some sort. The analysis currently does not describe the exact field it is worried about.

To unpack this a little, the analysis is saying the following can happen:

* ExpressionDecompiler contains some pointer to a GC thing. For example, it might have a field 'obj' of type 'JSObject*'.
* DecompileExpressionFromStack is called.
* A pointer is stored in that field of the 'ed' variable.
* decompilePC is invoked, which calls ValueToSource, which calls Invoke, which eventually calls js::MinorGC
* during the resulting garbage collection, the object pointed to by ed.obj is moved to a different location. All pointers stored in the JS heap are updated automatically, as are all rooted pointers. ed.obj is not, because the GC doesn't know about it.
* after decompilePC returns, something accesses ed.obj. This is now a stale pointer, and may refer to just about anything -- the wrong object, an invalid object, or whatever. Badness 10000, as TeX would say.

=== Analysis implementation ===

These builds are performed as follows:

* run the script testing/taskcluster/scripts/builder/build-haz-linux.sh, which sets up a build environment and runs the analysis within it, then uploads the resulting files
** compile an optimized JS shell to later run the analysis
** compile the browser with gcc, using a slightly modified version of the sixgill (http://svn.sixgill.org) gcc plugin, producing a set of .xdb files describing everything encountered during the compilation
** analyze the .xdb files with scripts in js/src/devtools/rootAnalysis

=== Running the analysis ===

==== Pushing to try ====

The easiest way to run an analysis is to push to try with the trychooser line |try: -b do -p linux64-haz| (or, if the hazards of interest are contained entirely within js/src, use |try: -b do -p linux64-shell-haz| for a much faster result). The expected turnaround time for linux64-haz is just under 2 hours.

The output will be uploaded and a link named "results" will be placed into the "job details" info pane on treeherder. If the analysis fails, you will see the number of failures. Navigate to the hazards.txt.gz file.

==== Running locally ====

To run the browser analysis, you must be on a Fedora/RedHat/CentOS linux64 machine. See js/src/devtools/rootAnalysis/README.md.

If you are running Debian or Ubuntu, then there is currently a problem running the full browser analysis. You can coerce the shell-only build to work by doing something like:

sudo apt-get install autoconf2.13 libnspr4 libnspr4-dev
sudo ln -s autoconf2.13 /usr/bin/autoconf-2.13
export CFLAGS="-B/usr/lib/x86_64-linux-gnu -I/usr/include/x86_64-linux-gnu"
export CXXFLAGS="-B/usr/lib/x86_64-linux-gnu -I/usr/include/x86_64-linux-gnu"

before running the script.

=== So you broke the analysis by adding a hazard. Now what? ===

Backout, fix the hazard, or (final resort) update the expected number of hazards in js/src/devtools/rootAnalysis/expect.browser.json.

The most common way to fix a hazard is to change the variable to be a Rooted type, as described in http://dxr.mozilla.org/mozilla-central/source/js/public/RootingAPI.h#l21

For more complicated cases, ask on #jsapi. If you don't get a response, ping sfink, terrence, or jonco.

Sheriffing/How To/Unified Repos

2016-06-23T04:22:38Z

Sfink: /* Backouts */ fmting

== Unified Repos ==
* http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html

=== Setting up the repo ===
* Set up your ssh key yourself
* Install Mercurial 3.2 or higher
* Make a copy of your .hgrc file for safekeeping and delete the original
* hg clone https://hg.mozilla.org/mozilla-central
* cd mozilla-central
* ./mach mercurial-setup
Configure mercurial as desired 
The following will pull all (or at least most) of the branches sheriffs need to have on hand:
* hg pull inbound && hg pull fx-team && hg pull aurora && hg pull beta && hg pull esr38
If you need other branches, you can find their names in the [https://hg.mozilla.org/hgcustom/version-control-tools/file/default/pylib/mozautomation/mozautomation/repository.py firefoxtree extension source].

You should now have everything set up for proper use! 

Maybe rename the folder from "mozilla-central" to "unifiedrepo" or something to make it clear it's more than just mozilla-central?

The `hg fxheads` command should list references to each of the relevant branch names, and the current revision and commit message for each.

With [https://bugzilla.mozilla.org/show_bug.cgi?id=1116861 bug 1116861] landed in version-control-tools, you can now use the following commands to pull from groups of repositories with a single command:
* hg pull fxtrees # this will pull from all branches listed with the fxheads command
* hg pull integration # this will pull from the mozilla-inbound, b2g-inbound, and fx-team branches
* hg pull releases # this will pull from pretty much every release branch (FYI: including old, unused branches)

=== Merges ===
This assumes you have your unified repo all set up so that `hg fxheads` lists each of central, b2ginbound, fx-team, and inbound.

To merge a specific non-tip <revision> from mozilla-inbound to mozilla-central:
# hg pull central
# hg pull inbound
# hg up central
# hg merge -r <revision>
# hg commit -m "Merge mozilla-inbound to mozilla-central a=merge"
# hg push -r . central

To merge mozilla-central into mozilla-inbound:
# hg pull central
# hg pull inbound
# hg up inbound
# hg merge central
# hg commit -m "Merge mozilla-central to mozilla-inbound a=merge"
# hg push -r . inbound

* If the `hg merge central` command results in "abort: nothing to merge", you should instead use `hg update -r <mozilla-central's tip revision>` to do a non-merging update, then you can do `hg push -r . inbound` to push it as usual.

=== Checkin-neededs ===
This assumes we're checking things in to fx-team. Replace fx-team with another branch name as needed.

===== Single repository and single set of patches =====
Update fx-team and prepare for the patches:
* hg pull fx-team
* hg up fx-team
* hg bookmark fx-team-checkins
Import the patches:
* hg import https://link.to/correct/checkin-needed.patch
* Repeat ^ as needed for all fx-team checkin-needed patches
Verify your outgoing changes:
* hg out -r . fx-team
If you haven't lost a push race:
* hg push -r . fx-team
If you lost a push race:
* hg pull fx-team
* hg rebase -d fx-team
* hg push -r . fx-team
Delete your no longer needed bookmark:
* hg bookmark -d fx-team-checkins

===== Multiple repositories with a single set of patches each =====
You can set up multiple sets of patches at once against multiple repositories:
Update fx-team
* hg pull fx-team && hg up fx-team
Create a bookmark to base your fx-team checkin-needed patches
* hg bookmark fxteam-checkins
Import a bunch of patches against fx-team
* hg import <patch1>
* hg import <patch2>
Update inbound and make a bookmark for inbound patches
* hg pull inbound && hg up inbound && hg bookmark inbound-checkins
Import some patches against inbound
* hg import <patch3>
* hg import <patch4>
See what you'd be pushing to inbound and push it
* hg out -r . inbound # this will only show patch3 and patch4
* hg push -r . inbound # this only pushes patch3 and patch4
* hg bookmark -d inbound-checkins # delete inbound's checkin bookmark as it's not needed
Go back to your fx-team checkins and add another patch to the bookmark, then push it
* hg up fxteam-checkins
* hg import <patch5>
* hg out -r . fx-team # this will be patch1, patch2, and patch5
* hg push -r . fx-team
* hg bookmark -d fxteam-checkins

===== Single repository with multiple sets of patches =====
Or have multiple sets of patches against a single repository:
Update fx-team
* hg pull fx-team && hg up fx-team
Make the first bookmark/set
* hg bookmark fxteam-checkins-1
* hg import <patch1>
* hg import <patch2>
Make the second set
* hg up fx-team && hg bookmark fxteam-checkins-2
* hg import <patch3>
* hg import <patch4>
See what's going to be pushed in each
* hg out -r . fx-team # patch3 and patch4
* hg up fxteam-checkins-1 && hg out -r . fx-team # patch1 and patch2
Push the first set
* hg push -r . fx-team # pushes patch1 and patch2
Get ready to push the second set
* hg up fxteam-checkins-2
* hg rebase -d fx-team # Rebase the second set onto the now-pushed first set
And push it
* hg push -r . fx-team # pushes patch3 and patch4
Delete the now-unneeded bookmarks
* hg bookmark -d fxteam-checkins-1
* hg bookmark -d fxteam-checkins-2

=== Uplifts ===
If branch-specific patches are posted, follow the checkin-needed instructions above, importing the patches onto the release branch.

If you're uplifting directly from an m-c checkin to aurora:

Pull and update to prepare for the uplifts:
* hg pull central
* hg pull aurora
* hg up aurora
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:
* hg graft --edit -r <revision>
Repeat the previous step as needed for all uplifts as needed.
Verify the outgoing changes and push:
* hg out -r . aurora
* hg push -r . aurora

You can graft a range of commits at once if that's easier:
* hg graft -r <toprevision>::<bottomrevision>

Read the documentation for [https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html#uplifting-backporting-commits graft] for further help.

=== Backouts ===
Better tools are coming:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1117632
* https://bugzilla.mozilla.org/show_bug.cgi?id=1121211
 

The standard backout command makes backing out revisions more difficult than it should, as it won't pre-fill the backout commit message with a bug number:
* Copy backout <revision> from treeherder, note the bug <number>, and remember the <reason>
* hg backout -r <revision>
** This should open up your editor with a completely empty commit message. Type in the backout message like "Backout revision <revision> (bug <number>) for <reason>" (possibly with "CLOSED TREE" in there to get around a closure hook).
* hg push -r . <tree>

[https://hg.mozilla.org/hgcustom/version-control-tools/file/4e7ab9638cf0/hgext/qbackout qbackout] can still be used, though you will want to use `hg oops` in place of `hg qbackout` (eg if you use `hg share` to get multiple working directories, qbackout and other uses of mq do not play nice with shared repos):
* Copy the backout <revision> from treeherder
* hg oops -e -r <revision>
** This should open up your editor with a prepopulated commit message like "Backed out <revision> (bug <number>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* hg out -r . <tree>
** to double-check what you will be pushing
* hg push -r . <tree>

qbackout can also back out a range of commits in a single backout commit:
* hg oops -e -s -r <toprevision>:<bottomrevision>
** This will open your editor with a prepopulated commit message like "Backed out <toprevision>,<anymiddlerevisions>,<bottomrevision> (bug <number>,any other bug <numbers>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* hg push -r . <tree>
(Omit oops's -s flag to back out each individual revision in the range as a separate commit.)

==== Revert a backout ====
* `hg graft`, see https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/common.html#revive-a-commit-that-was-backed-out

=== Rebasing after losing a push race ===
This assumes you have commits you're attempting to push to mozilla-inbound when you lose a push race with someone. Change `inbound` to the correct branch name as needed.

* hg pull inbound
* hg rebase -d inbound
* hg push -r . inbound

=== Recovering from mistakes ===
<big>WARNING:</big> This will strip out any commits that haven't been pushed to the remote repositories, regardless of what branch/label/tag those commits are on. (So if you have local changes on inbound and run this command to strip something bad on fx-team, both inbound and fx-team will be stripped.) Only do this if you don't care about any of those commits!
* hg strip 'not public()'

You may also need to use some combination of the following to get things back to a known-good state:
* hg purge # http://mercurial.selenic.com/wiki/PurgeExtension
* hg up -C

=== See what you're about to push ===
`hg out` without any flags added will show you a LOT of unrelated commits. To see just what you'll be pushing to a given branch, use `hg out -r . <branch>`
* hg out -r . inbound
** This will only display the things you're about to push to the inbound branch

=== View incoming changes ===
Since your unified repo will likely have all changesets from the various branches pulled locally, `hg in <somebranch> -r <somerev>` will likely not help you see what would be pulled into your current branch from <somebranch> up to that <somerev>.
Instead, you can use the following to print out the equivalent. Say you want to see what would be merged onto mozilla-central from b2g-inbound's revision ca142ec8ba0f:

Make sure m-c is fully up to date:
* hg pull central
* hg up central
Get all of b2g-inbound's changesets:
* hg pull b2ginbound
Do a preview of the merge without actually performing the merge:
* hg merge -r ca142ec8ba0f -P
This will print out everything on b2g-inbound (up to and including revision ca142ec8ba0f) that is not already on mozilla-central.

=== See the log for a particular branch ===
* hg log -fr [branch]

= Extras =
== hg aliases ==
I set up the following aliases in my global .hgrc file to make merging things around trunk a little faster:
[alias]
# merge tree $1, revision $2 to central, optionally appending $3 (for "CLOSED TREE", etc)
mergetocentral = !$HG pull central ; $HG up central ; $HG pull $1 ; $HG merge $2 ; $HG commit -m "Merge $1 to central, a=merge $3" ; $HG push -r . central
# merge central tip to tree $1, optionally appending $2 (for "CLOSED TREE", etc)
mergetointegration = !$HG pull central ; $HG pull $1 ; $HG up $1 ; $HG merge central ; $HG commit -m "Merge m-c to $1, a=merge $2" ; $HG push -r . $1

With these set up, I can merge fx-team's revision 04a3d9130aa0 over to mozilla-central with the following command:
hg mergetocentral fx-team 04a3d9130aa0
and then I can merge mozilla-central's tip back to fx-team with the following command:
hg mergetointegration fx-team
This cuts down on a lot of repetitive typing, saving a bit of time.

For merging from reviewboard patches, there's this alias
rbimport = !hg transplant -e -s https://reviewboard-hg.mozilla.org/gecko -b $1

Then, it's matter of importing the right hash like the following command:
hg rbimport dd1462ba321db983061b94e30cee92b6bd81e908

Sheriffing/How To/Unified Repos

2016-06-23T04:21:39Z

Sfink: /* Backouts */ backticks do not format code

== Unified Repos ==
* http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html

=== Setting up the repo ===
* Set up your ssh key yourself
* Install Mercurial 3.2 or higher
* Make a copy of your .hgrc file for safekeeping and delete the original
* hg clone https://hg.mozilla.org/mozilla-central
* cd mozilla-central
* ./mach mercurial-setup
Configure mercurial as desired 
The following will pull all (or at least most) of the branches sheriffs need to have on hand:
* hg pull inbound && hg pull fx-team && hg pull aurora && hg pull beta && hg pull esr38
If you need other branches, you can find their names in the [https://hg.mozilla.org/hgcustom/version-control-tools/file/default/pylib/mozautomation/mozautomation/repository.py firefoxtree extension source].

You should now have everything set up for proper use! 

Maybe rename the folder from "mozilla-central" to "unifiedrepo" or something to make it clear it's more than just mozilla-central?

The `hg fxheads` command should list references to each of the relevant branch names, and the current revision and commit message for each.

With [https://bugzilla.mozilla.org/show_bug.cgi?id=1116861 bug 1116861] landed in version-control-tools, you can now use the following commands to pull from groups of repositories with a single command:
* hg pull fxtrees # this will pull from all branches listed with the fxheads command
* hg pull integration # this will pull from the mozilla-inbound, b2g-inbound, and fx-team branches
* hg pull releases # this will pull from pretty much every release branch (FYI: including old, unused branches)

=== Merges ===
This assumes you have your unified repo all set up so that `hg fxheads` lists each of central, b2ginbound, fx-team, and inbound.

To merge a specific non-tip <revision> from mozilla-inbound to mozilla-central:
# hg pull central
# hg pull inbound
# hg up central
# hg merge -r <revision>
# hg commit -m "Merge mozilla-inbound to mozilla-central a=merge"
# hg push -r . central

To merge mozilla-central into mozilla-inbound:
# hg pull central
# hg pull inbound
# hg up inbound
# hg merge central
# hg commit -m "Merge mozilla-central to mozilla-inbound a=merge"
# hg push -r . inbound

* If the `hg merge central` command results in "abort: nothing to merge", you should instead use `hg update -r <mozilla-central's tip revision>` to do a non-merging update, then you can do `hg push -r . inbound` to push it as usual.

=== Checkin-neededs ===
This assumes we're checking things in to fx-team. Replace fx-team with another branch name as needed.

===== Single repository and single set of patches =====
Update fx-team and prepare for the patches:
* hg pull fx-team
* hg up fx-team
* hg bookmark fx-team-checkins
Import the patches:
* hg import https://link.to/correct/checkin-needed.patch
* Repeat ^ as needed for all fx-team checkin-needed patches
Verify your outgoing changes:
* hg out -r . fx-team
If you haven't lost a push race:
* hg push -r . fx-team
If you lost a push race:
* hg pull fx-team
* hg rebase -d fx-team
* hg push -r . fx-team
Delete your no longer needed bookmark:
* hg bookmark -d fx-team-checkins

===== Multiple repositories with a single set of patches each =====
You can set up multiple sets of patches at once against multiple repositories:
Update fx-team
* hg pull fx-team && hg up fx-team
Create a bookmark to base your fx-team checkin-needed patches
* hg bookmark fxteam-checkins
Import a bunch of patches against fx-team
* hg import <patch1>
* hg import <patch2>
Update inbound and make a bookmark for inbound patches
* hg pull inbound && hg up inbound && hg bookmark inbound-checkins
Import some patches against inbound
* hg import <patch3>
* hg import <patch4>
See what you'd be pushing to inbound and push it
* hg out -r . inbound # this will only show patch3 and patch4
* hg push -r . inbound # this only pushes patch3 and patch4
* hg bookmark -d inbound-checkins # delete inbound's checkin bookmark as it's not needed
Go back to your fx-team checkins and add another patch to the bookmark, then push it
* hg up fxteam-checkins
* hg import <patch5>
* hg out -r . fx-team # this will be patch1, patch2, and patch5
* hg push -r . fx-team
* hg bookmark -d fxteam-checkins

===== Single repository with multiple sets of patches =====
Or have multiple sets of patches against a single repository:
Update fx-team
* hg pull fx-team && hg up fx-team
Make the first bookmark/set
* hg bookmark fxteam-checkins-1
* hg import <patch1>
* hg import <patch2>
Make the second set
* hg up fx-team && hg bookmark fxteam-checkins-2
* hg import <patch3>
* hg import <patch4>
See what's going to be pushed in each
* hg out -r . fx-team # patch3 and patch4
* hg up fxteam-checkins-1 && hg out -r . fx-team # patch1 and patch2
Push the first set
* hg push -r . fx-team # pushes patch1 and patch2
Get ready to push the second set
* hg up fxteam-checkins-2
* hg rebase -d fx-team # Rebase the second set onto the now-pushed first set
And push it
* hg push -r . fx-team # pushes patch3 and patch4
Delete the now-unneeded bookmarks
* hg bookmark -d fxteam-checkins-1
* hg bookmark -d fxteam-checkins-2

=== Uplifts ===
If branch-specific patches are posted, follow the checkin-needed instructions above, importing the patches onto the release branch.

If you're uplifting directly from an m-c checkin to aurora:

Pull and update to prepare for the uplifts:
* hg pull central
* hg pull aurora
* hg up aurora
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:
* hg graft --edit -r <revision>
Repeat the previous step as needed for all uplifts as needed.
Verify the outgoing changes and push:
* hg out -r . aurora
* hg push -r . aurora

You can graft a range of commits at once if that's easier:
* hg graft -r <toprevision>::<bottomrevision>

Read the documentation for [https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html#uplifting-backporting-commits graft] for further help.

=== Backouts ===
Better tools are coming:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1117632
* https://bugzilla.mozilla.org/show_bug.cgi?id=1121211
 

The standard backout command makes backing out revisions more difficult than it should, as it won't pre-fill the backout commit message with a bug number:
* Copy backout <revision> from treeherder, note the bug <number>, and remember the <reason>
* hg backout -r <revision>
** This should open up your editor with a completely empty commit message. Type in the backout message like "Backout revision <revision> (bug <number>) for <reason>" (possibly with "CLOSED TREE" in there to get around a closure hook).
* hg push -r . <tree>

[https://hg.mozilla.org/hgcustom/version-control-tools/file/4e7ab9638cf0/hgext/qbackout qbackout] can still be used, though you will want to use `hg oops` in place of `hg qbackout` (eg if you use `hg share` to get multiple working directories, qbackout and other uses of mq do not play nice with shared repos):
* Copy the backout <revision> from treeherder
* hg oops -e -r <revision>
** This should open up your editor with a prepopulated commit message like "Backed out <revision> (bug <number>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* hg out -r . <tree> ''(to double-check what you will be pushing)''
* hg push -r . <tree>

qbackout can also back out a range of commits in a single backout commit:
* hg oops -e -s -r <toprevision>:<bottomrevision>
** This will open your editor with a prepopulated commit message like "Backed out <toprevision>,<anymiddlerevisions>,<bottomrevision> (bug <number>,any other bug <numbers>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* hg push -r . <tree>
(Omit oops's -s flag to back out each individual revision in the range as a separate commit.)

==== Revert a backout ====
* `hg graft`, see https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/common.html#revive-a-commit-that-was-backed-out

=== Rebasing after losing a push race ===
This assumes you have commits you're attempting to push to mozilla-inbound when you lose a push race with someone. Change `inbound` to the correct branch name as needed.

* hg pull inbound
* hg rebase -d inbound
* hg push -r . inbound

=== Recovering from mistakes ===
<big>WARNING:</big> This will strip out any commits that haven't been pushed to the remote repositories, regardless of what branch/label/tag those commits are on. (So if you have local changes on inbound and run this command to strip something bad on fx-team, both inbound and fx-team will be stripped.) Only do this if you don't care about any of those commits!
* hg strip 'not public()'

You may also need to use some combination of the following to get things back to a known-good state:
* hg purge # http://mercurial.selenic.com/wiki/PurgeExtension
* hg up -C

=== See what you're about to push ===
`hg out` without any flags added will show you a LOT of unrelated commits. To see just what you'll be pushing to a given branch, use `hg out -r . <branch>`
* hg out -r . inbound
** This will only display the things you're about to push to the inbound branch

=== View incoming changes ===
Since your unified repo will likely have all changesets from the various branches pulled locally, `hg in <somebranch> -r <somerev>` will likely not help you see what would be pulled into your current branch from <somebranch> up to that <somerev>.
Instead, you can use the following to print out the equivalent. Say you want to see what would be merged onto mozilla-central from b2g-inbound's revision ca142ec8ba0f:

Make sure m-c is fully up to date:
* hg pull central
* hg up central
Get all of b2g-inbound's changesets:
* hg pull b2ginbound
Do a preview of the merge without actually performing the merge:
* hg merge -r ca142ec8ba0f -P
This will print out everything on b2g-inbound (up to and including revision ca142ec8ba0f) that is not already on mozilla-central.

=== See the log for a particular branch ===
* hg log -fr [branch]

= Extras =
== hg aliases ==
I set up the following aliases in my global .hgrc file to make merging things around trunk a little faster:
[alias]
# merge tree $1, revision $2 to central, optionally appending $3 (for "CLOSED TREE", etc)
mergetocentral = !$HG pull central ; $HG up central ; $HG pull $1 ; $HG merge $2 ; $HG commit -m "Merge $1 to central, a=merge $3" ; $HG push -r . central
# merge central tip to tree $1, optionally appending $2 (for "CLOSED TREE", etc)
mergetointegration = !$HG pull central ; $HG pull $1 ; $HG up $1 ; $HG merge central ; $HG commit -m "Merge m-c to $1, a=merge $2" ; $HG push -r . $1

With these set up, I can merge fx-team's revision 04a3d9130aa0 over to mozilla-central with the following command:
hg mergetocentral fx-team 04a3d9130aa0
and then I can merge mozilla-central's tip back to fx-team with the following command:
hg mergetointegration fx-team
This cuts down on a lot of repetitive typing, saving a bit of time.

For merging from reviewboard patches, there's this alias
rbimport = !hg transplant -e -s https://reviewboard-hg.mozilla.org/gecko -b $1

Then, it's matter of importing the right hash like the following command:
hg rbimport dd1462ba321db983061b94e30cee92b6bd81e908

Sheriffing/How To/Unified Repos

2016-06-23T04:16:44Z

Sfink: /* Backouts */ switch to hg oops

== Unified Repos ==
* http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html

=== Setting up the repo ===
* Set up your ssh key yourself
* Install Mercurial 3.2 or higher
* Make a copy of your .hgrc file for safekeeping and delete the original
* hg clone https://hg.mozilla.org/mozilla-central
* cd mozilla-central
* ./mach mercurial-setup
Configure mercurial as desired 
The following will pull all (or at least most) of the branches sheriffs need to have on hand:
* hg pull inbound && hg pull fx-team && hg pull aurora && hg pull beta && hg pull esr38
If you need other branches, you can find their names in the [https://hg.mozilla.org/hgcustom/version-control-tools/file/default/pylib/mozautomation/mozautomation/repository.py firefoxtree extension source].

You should now have everything set up for proper use! 

Maybe rename the folder from "mozilla-central" to "unifiedrepo" or something to make it clear it's more than just mozilla-central?

The `hg fxheads` command should list references to each of the relevant branch names, and the current revision and commit message for each.

With [https://bugzilla.mozilla.org/show_bug.cgi?id=1116861 bug 1116861] landed in version-control-tools, you can now use the following commands to pull from groups of repositories with a single command:
* hg pull fxtrees # this will pull from all branches listed with the fxheads command
* hg pull integration # this will pull from the mozilla-inbound, b2g-inbound, and fx-team branches
* hg pull releases # this will pull from pretty much every release branch (FYI: including old, unused branches)

=== Merges ===
This assumes you have your unified repo all set up so that `hg fxheads` lists each of central, b2ginbound, fx-team, and inbound.

To merge a specific non-tip <revision> from mozilla-inbound to mozilla-central:
# hg pull central
# hg pull inbound
# hg up central
# hg merge -r <revision>
# hg commit -m "Merge mozilla-inbound to mozilla-central a=merge"
# hg push -r . central

To merge mozilla-central into mozilla-inbound:
# hg pull central
# hg pull inbound
# hg up inbound
# hg merge central
# hg commit -m "Merge mozilla-central to mozilla-inbound a=merge"
# hg push -r . inbound

* If the `hg merge central` command results in "abort: nothing to merge", you should instead use `hg update -r <mozilla-central's tip revision>` to do a non-merging update, then you can do `hg push -r . inbound` to push it as usual.

=== Checkin-neededs ===
This assumes we're checking things in to fx-team. Replace fx-team with another branch name as needed.

===== Single repository and single set of patches =====
Update fx-team and prepare for the patches:
* hg pull fx-team
* hg up fx-team
* hg bookmark fx-team-checkins
Import the patches:
* hg import https://link.to/correct/checkin-needed.patch
* Repeat ^ as needed for all fx-team checkin-needed patches
Verify your outgoing changes:
* hg out -r . fx-team
If you haven't lost a push race:
* hg push -r . fx-team
If you lost a push race:
* hg pull fx-team
* hg rebase -d fx-team
* hg push -r . fx-team
Delete your no longer needed bookmark:
* hg bookmark -d fx-team-checkins

===== Multiple repositories with a single set of patches each =====
You can set up multiple sets of patches at once against multiple repositories:
Update fx-team
* hg pull fx-team && hg up fx-team
Create a bookmark to base your fx-team checkin-needed patches
* hg bookmark fxteam-checkins
Import a bunch of patches against fx-team
* hg import <patch1>
* hg import <patch2>
Update inbound and make a bookmark for inbound patches
* hg pull inbound && hg up inbound && hg bookmark inbound-checkins
Import some patches against inbound
* hg import <patch3>
* hg import <patch4>
See what you'd be pushing to inbound and push it
* hg out -r . inbound # this will only show patch3 and patch4
* hg push -r . inbound # this only pushes patch3 and patch4
* hg bookmark -d inbound-checkins # delete inbound's checkin bookmark as it's not needed
Go back to your fx-team checkins and add another patch to the bookmark, then push it
* hg up fxteam-checkins
* hg import <patch5>
* hg out -r . fx-team # this will be patch1, patch2, and patch5
* hg push -r . fx-team
* hg bookmark -d fxteam-checkins

===== Single repository with multiple sets of patches =====
Or have multiple sets of patches against a single repository:
Update fx-team
* hg pull fx-team && hg up fx-team
Make the first bookmark/set
* hg bookmark fxteam-checkins-1
* hg import <patch1>
* hg import <patch2>
Make the second set
* hg up fx-team && hg bookmark fxteam-checkins-2
* hg import <patch3>
* hg import <patch4>
See what's going to be pushed in each
* hg out -r . fx-team # patch3 and patch4
* hg up fxteam-checkins-1 && hg out -r . fx-team # patch1 and patch2
Push the first set
* hg push -r . fx-team # pushes patch1 and patch2
Get ready to push the second set
* hg up fxteam-checkins-2
* hg rebase -d fx-team # Rebase the second set onto the now-pushed first set
And push it
* hg push -r . fx-team # pushes patch3 and patch4
Delete the now-unneeded bookmarks
* hg bookmark -d fxteam-checkins-1
* hg bookmark -d fxteam-checkins-2

=== Uplifts ===
If branch-specific patches are posted, follow the checkin-needed instructions above, importing the patches onto the release branch.

If you're uplifting directly from an m-c checkin to aurora:

Pull and update to prepare for the uplifts:
* hg pull central
* hg pull aurora
* hg up aurora
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:
* hg graft --edit -r <revision>
Repeat the previous step as needed for all uplifts as needed.
Verify the outgoing changes and push:
* hg out -r . aurora
* hg push -r . aurora

You can graft a range of commits at once if that's easier:
* hg graft -r <toprevision>::<bottomrevision>

Read the documentation for [https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html#uplifting-backporting-commits graft] for further help.

=== Backouts ===
Better tools are coming:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1117632
* https://bugzilla.mozilla.org/show_bug.cgi?id=1121211
 

The standard backout command makes backing out revisions more difficult than it should, as it won't pre-fill the backout commit message with a bug number:
* Copy backout <revision> from treeherder, note the bug <number>, and remember the <reason>
* `hg backout -r <revision>`
** This should open up your editor with a completely empty commit message. Type in the backout message like "Backout revision <revision> (bug <number>) for <reason>" (possibly with "CLOSED TREE" in there to get around a closure hook).
* `hg push -r . <tree>`

[https://hg.mozilla.org/hgcustom/version-control-tools/file/4e7ab9638cf0/hgext/qbackout qbackout] can still be used, though you will want to use `hg oops` in place of `hg qbackout` (eg if you use `hg share` to get multiple working directories, qbackout and other uses of mq do not play nice with shared repos):
* Copy the backout <revision> from treeherder
* `hg oops -e -r <revision>`
** This should open up your editor with a prepopulated commit message like "Backed out <revision> (bug <number>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg out -r . <tree>` to double-check what you will be pushing
* `hg push -r . <tree>`

qbackout can also back out a range of commits in a single backout commit:
* `hg oops -e -s -r <toprevision>:<bottomrevision>`
** This will open your editor with a prepopulated commit message like "Backed out <toprevision>,<anymiddlerevisions>,<bottomrevision> (bug <number>,any other bug <numbers>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg push -r . <tree>`
(Omit oops's -s flag to back out each individual revision in the range as a separate commit.)

==== Revert a backout ====
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/common.html#revive-a-commit-that-was-backed-out

=== Rebasing after losing a push race ===
This assumes you have commits you're attempting to push to mozilla-inbound when you lose a push race with someone. Change `inbound` to the correct branch name as needed.

* hg pull inbound
* hg rebase -d inbound
* hg push -r . inbound

=== Recovering from mistakes ===
<big>WARNING:</big> This will strip out any commits that haven't been pushed to the remote repositories, regardless of what branch/label/tag those commits are on. (So if you have local changes on inbound and run this command to strip something bad on fx-team, both inbound and fx-team will be stripped.) Only do this if you don't care about any of those commits!
* hg strip 'not public()'

You may also need to use some combination of the following to get things back to a known-good state:
* hg purge # http://mercurial.selenic.com/wiki/PurgeExtension
* hg up -C

=== See what you're about to push ===
`hg out` without any flags added will show you a LOT of unrelated commits. To see just what you'll be pushing to a given branch, use `hg out -r . <branch>`
* hg out -r . inbound
** This will only display the things you're about to push to the inbound branch

=== View incoming changes ===
Since your unified repo will likely have all changesets from the various branches pulled locally, `hg in <somebranch> -r <somerev>` will likely not help you see what would be pulled into your current branch from <somebranch> up to that <somerev>.
Instead, you can use the following to print out the equivalent. Say you want to see what would be merged onto mozilla-central from b2g-inbound's revision ca142ec8ba0f:

Make sure m-c is fully up to date:
* hg pull central
* hg up central
Get all of b2g-inbound's changesets:
* hg pull b2ginbound
Do a preview of the merge without actually performing the merge:
* hg merge -r ca142ec8ba0f -P
This will print out everything on b2g-inbound (up to and including revision ca142ec8ba0f) that is not already on mozilla-central.

=== See the log for a particular branch ===
* hg log -fr [branch]

= Extras =
== hg aliases ==
I set up the following aliases in my global .hgrc file to make merging things around trunk a little faster:
[alias]
# merge tree $1, revision $2 to central, optionally appending $3 (for "CLOSED TREE", etc)
mergetocentral = !$HG pull central ; $HG up central ; $HG pull $1 ; $HG merge $2 ; $HG commit -m "Merge $1 to central, a=merge $3" ; $HG push -r . central
# merge central tip to tree $1, optionally appending $2 (for "CLOSED TREE", etc)
mergetointegration = !$HG pull central ; $HG pull $1 ; $HG up $1 ; $HG merge central ; $HG commit -m "Merge m-c to $1, a=merge $2" ; $HG push -r . $1

With these set up, I can merge fx-team's revision 04a3d9130aa0 over to mozilla-central with the following command:
hg mergetocentral fx-team 04a3d9130aa0
and then I can merge mozilla-central's tip back to fx-team with the following command:
hg mergetointegration fx-team
This cuts down on a lot of repetitive typing, saving a bit of time.

For merging from reviewboard patches, there's this alias
rbimport = !hg transplant -e -s https://reviewboard-hg.mozilla.org/gecko -b $1

Then, it's matter of importing the right hash like the following command:
hg rbimport dd1462ba321db983061b94e30cee92b6bd81e908

Sfink/Memory Ideas

2016-06-04T23:46:42Z

Sfink: /* Problem F: Hard to track down problems */ Remove hard breaks to fix formatting

== Problem A: System too unusable to diagnose ==

When a bad memory leak kicks in, the system can be too unusable to get useful data out.

=== Solutions: Make it easier to get information out when the system is suffering ===

[[#A1]] Periodically log memory-related information (existing bug, I think? also
telemetry)

[[#A2]] Maintain a rotating database of detailed memory-related information (cf
atop)

[[#A3]] Make about:memory capable of outputting to a file, for use with a
command-line invocation 'firefox about:memory?verbose=1&outfile=...'

=== Solution: Prevent the system from getting into such a bad state ===

[[#A4]] Make a per-compartment (or per-?) cap on memory usage

[[#A5]] When sufferingMode==true, disable GC/CC on big tabs. Probably need to
deactivate them too.

[[#A6]] Early warning when memory usage is getting too high

[[#A7]] Crash reporter-like UI for reporting memory problems (do not require an
actual crash to trigger)

== Problem B: Regular users can't generate useful reports ==

Hard for regular users to generate a useful memory problem report

(all solutions from problem A are relevant here)

[[#B1]] Provide a way to dump and submit a reachability graph

[[#B2]] Documentation for how to best help with a memory problem, with various
steps to follow.

[[#B3]] Track memory to individual page/tab/compartment/principals.

[[#B4]] Tools for generating profiles with subsets of addons installed (or for
running with different subsets of addons within one profile)

[[#B5]] Tools for blaming memory usage on addons (eg detecting "safe" addons to
remove from consideration. Cross-referencing other users' addons and memory
usage similar to the crash correlation reports -- requires telemetry.)

== Problem C: Knowledgeable users can't generate useful reports ==

Hard for developers or knowledgeable and motivated users to generate
a useful memory problem report

The above problem B crossed into this, so everything there is relevant.

[[#C1]] Rationalize and document all of our various leak-detection tools.

[[#C2]] Automation and Windows equivalents of my /proc/<pid>/maps hacks

[[#C3]] Dumpers that give full heap, full graph, pruned graph. Visualizers,
analyzers, etc. of the dumps.

[[#C4]] Collect age of various memory objects (how many CCs or GCs it has been
alive.)

== Problem D: Uncollected garbage ==

Garbage is not collected

=== Solution: Report cycles that CC misses ===

[[#D1]] Conservative scanner to find cycles involving things not marked as
CC-participants and report them as suspicious.

=== Solution: Report resources that leak over time but are still referenced (so they are cleaned up before shutdown) ===

[[#D2]] Register "expected lifetime" at acquisition time. Report things that live
longer than expected, filtered by diagnostics. ("lifetime assertions"? Not
quite.)

[[#D3]] Detect subgraphs that grow (at a constant rate?) while a page is open.

[[#D4]] Detect subgraphs that are never accessed

== Problem E: Unleaked but excessive memory usage ==

High memory usage, not leaked

(aside from current work like generational gc)

[[#E1]] "Simulator" that runs over logs and estimates peak memory usage if CC/GC
ran at optimal times.

[[#E2]] Use reproducible test runs to evaluate what the performance/memory
tradeoff is for various things (eg jit code, structure sizes)

== Problem F: Hard to track down problems ==

Hard to navigate through a memory dump or the current state to track
down a specific problem

[[#F1]] Dump all roots of a compartment, and trace roots back to the XPCOM/DOM/whatever thing that is holding onto that root (when available)

[[#F2]] Go from JS object to things keeping it alive (dump out GC edges) -- see jimb's findReferences (currently JS shell only)

[[#F3]] Record addr,size,stack at every allocation (kgadd's heap visualizer)

[[#F4]]

----------------------------------------------------------------------

Details:

<div id='A2'>A2. atop records a ton of statistics about memory, disk, network, CPU, and other things at a 10 minute sampling interval. Stats are collected both on a global and per-process granularity. It monitors every process that starts and stops, even if the process appeared and disappeared entirely between two samples. It dumps all this in a somewhat-compressed binary log.

The visual UI has a good set of heuristics for detecting "large" values, and coloring the output accordingly. If your disk is busy for >90% of the sampling interval, it'll turn red. If your network traffic is a high percentage of the expected maximum bandwidth, it'll turn red. etc.

It lets you use it in 'top-like' mode, where it displays the current state of things, as well as in a historical mode where it reads from a log file. (It is decidedly *not* seamless between the two, but it should be.)

It also allows dumping historical data to text files. I've used that for generating graphs of various values.

For the browser, many of the same metrics are applicable, but I'd also like an equivalent of the processes' info. The idea is to know "what was going on at
XXX?" So it should be user and browser actions, which tab was active, network requests, significant events firing, etc.

</div>
----

<div id='A3'>A3. The idea is that rather than waiting for the screen to redraw for every action in getting to about:memory, you just do firefox 'about:memory...' and go have a cup of tea while it thinks about it.

</div>
----

<div id='A5'>A5. This is based on pure speculation, but I don't understand why the browser is so incredibly unusable when memory usage is going nuts. Why is all that memory being touched? Why isn't it just swapped out and forgotten? Under the assumption that it's the GC scanning it over and over again, it seems like it would be nice to suppress GC in this situation. Generational GC could eliminate this problem in a nicer and much more principled way.

</div>
----

<div id='B2'>B2. I have the impression that we have many, many memory-related problem reports that end up being useless. I think that's really our fault; it's too hard for users to file useful bug reports. Experienced Mozilla devs don't even know what to do.

</div>
----

<div id='B5'>B5. eg: collect up all API calls that an addon makes (or record them, or whatever.) Maintain a whitelist of APIs. (If you pass in a string, assume it may be duplicated a thousand times and stored in a sqlite DB forever, but if you're just setting existing booleans or reading state, you're blameless.)

</div>
----

<div id='C2'>C2. When looking at a memory leak, I took several snapshots of /proc/<pid>/maps, diffed them to find a memory region that appeared and did not disappear, and then dumped out the raw memory to a file. Then I ran strings on it.

</div>
----

<div id='D2'>D2. I don't really know enough about the system to flesh this out properly, but it seems like when you have a bunch of memory lingering around when it really ought to be dead, that many of the objects comprising that memory should be able to "know" that they *probably* shouldn't live past... the current page, or for more than a few seconds, or whatever. Assuming this is possible, it should be possible to walk up a dominator graph and give a fairly directed answer to "why has this outlived what it thought its lifespan would be?"

Not every memory allocation needs to be marked for this to work. You just need one object within the "leaked" memory to be marked.

It could also walk the graph "en masse" to ignore individual objects that are reachable longer than expected and focus on the clusters of objects that are kept alive by the same thing. (I'm thinking that the expected lifetime is a guess, and may be inaccurate.)

</div>
----

<div id='D4'>D4. eg use mprotect on a random subset of the heap to find pages (or smaller regions, but that's harder) that are never accessed after some point. Remove the GC/CC from consideration.
</div>

Javascript:Automation Builds

2016-05-23T20:54:50Z

Sfink: /* Reproducing a build */ warnaserr is obsolete