SpiderMonkey Newsletter #8

[Jan de Mooij]

 (This newsletter is also available on our blog
.)

SpiderMonkey is the JavaScript engine used in Mozilla Firefox. This
newsletter gives an overview of the JavaScript and WebAssembly work we’ve
done as part of the Firefox 84 and 85 Nightly release cycles.

If you like these newsletters, you may also enjoy Yulia’s Compiler Compiler
live stream
.

This has been an unusual year for many of us, but the team is proud of
everything we accomplished in 2020. Happy Holidays!
‍♀️ New features Firefox 84-85

   - André enabled 
   support for the fractionalSecondDigits option for Intl.DateTimeFormat.
   - André added 
   support for the collation option for Intl.Collator.

In progress

   - Tom implemented 
   the at() proposal
   
   (Nightly-only)
   - Yulia implemented
    support for top-level
   await  (disabled by
   default)

⚡ WebAssembly

   - Dmitry from Igalia landed
    patches to make
   the internal call ABI more efficient.
   - Julian enabled 
   the Cranelift compiler on ARM64 hardware (in Nightly).
   - Lars made  many
   changes to improve SIMD support.
   - Ryan simplified 
   the TypedObject code more by using Wasm’s type system.
   - Mike Hommey fixed
    crashes on Apple
   ARM64 hardware.
   - Jan prototyped 
   support for large (more than 2 GB) ArrayBuffers, DataViews and typed
   arrays. Lars did some work
    to take advantage
   of this for WebAssembly.
   - Asumu and Ioanna from Igalia started landing
    patches for Wasm
   exception handling.

❇️ Stencil

Stencil  is our
project to create an explicit interface between the frontend (parser,
bytecode emitter) and the rest of the VM, decoupling those components. This
lets us improve web-browsing performance, simplify a lot of code and
improve bytecode caching.

   - Ted made 
   line/column source notes relative to the initial line/column to allow more
   bytecode sharing.
   - Arai optimized 
   Stencil instantiation by moving more malloc allocations off-thread.
   - Arai and Ted landed
    many
    changes
    to
    optimize
   conversion from parser atoms to GC atoms.
   - Ted made  more
   parser atoms constexpr.
   - Arai replaced pointers to atoms
    and script-things
    with indexes to
   save memory and to optimize bytecode caching.
   - Ted used  a
   LifoAlloc (bump allocator) to speed up allocations for Stencil data
   structures.

 WarpBuilder

WarpBuilder  is the
JIT project to replace the frontend of our optimizing JIT (IonBuilder) and
the engine’s Type Inference mechanism with a new MIR builder based on
compiling CacheIR to MIR.

After enabling

Warp by default in Firefox 83, we started removing IonBuilder and TI in
Firefox 85. This has let us remove about 50,000 lines of complicated code.

   - Jan landed  more
   than 100 patches to remove most of the IonBuilder/TI code.
   - Ted and Tom also landed
    various
    changes
    to delete code we
   no longer needed.
   - Iain made  many
    changes
    to the bailout
   code to eliminate bailout 

SpiderMonkey Newsletter #7

[Jan de Mooij]

(This newsletter is also available on our blog
.)

SpiderMonkey is the JavaScript engine used in Mozilla Firefox. This
newsletter gives an overview of the JavaScript and WebAssembly work we’ve
done as part of the Firefox 82 and 83 Nightly release cycles.

If you like these newsletters, you may also enjoy Yulia’s Compiler Compiler
live stream

.
 New contributors

   - Yozaam optimized 
   part of our private fields implementation.

‍♀️ New features Firefox 82-83

   - Adam added 
   Reflect[Symbol.toStringTag] and Jeff added
   
   Intl[Symbol.toStringTag].

In progress

   - Tom implemented 
   the .item proposal , but
   this feature had to be backed out after a few days because it caused
   various web compatibility issues.
   - Yulia is making progress
    implementing
Top-level
   await .
   - Jessica from Igalia started
    implementing the
   Wasm type reflection proposal
   

   .
   - Ryan started 
   implementing the Wasm function-references proposal.
   - Ryan implemented 
   the Wasm *eqref* type.

 WarpBuilder

WarpBuilder  is the
JIT project to replace the frontend of our optimizing JIT (IonBuilder) and
the engine’s Type Inference mechanism with a new MIR builder based on
compiling CacheIR to MIR. WarpBuilder will let us improve security,
performance, memory usage and maintainability of the whole engine.

We have enabled 
WarpBuilder by default for Firefox 83  This resulted

in improved responsiveness, page load performance and memory usage.
Feedback from Nightly users has been very positive.

A few of the other Warp changes that landed the past months:

   - Iain landed  many
    improvements
    for (trial)
   inlining.
   - Jan added 
   getter/setter calls and
    optimized Wasm
   calls to the transpiler.
   - Tom ported optimizations for DOM getters
   , setters
   , methods
    and certain
   proxies .
   - Caroline made 
   changes  to improve
    the CacheIR
   analysis tool.
   - André added CacheIR optimizations for function.name
   ,
   arguments[Symbol.iterator]
   ,
   Object.prototype.isPrototypeOf
   .
   - Tom added 
   CacheIR optimizations for toString and valueOf on numbers and strings.
   - André implemented
    more
    CacheIR
   instructions in the transpiler.

粒 Garbage Collection

   - Jon added  a
   header to dynamic object slots to store the object slot span and capacity.
   - Jon refactored 
   the tracing interface and simplified
    how slots and
   elements are stored on the mark stack. These changes will help us
   experiment with concurrent marking.
   - Jon optimized 
   the GC barrier code.

❇️ Stencil

Stencil  is our
project to create an explicit interface between the frontend (parser,
bytecode emitter) and the rest of the VM, decoupling those components. This
lets us improve web-browsing 

Re: Dogfooding Warp

[Jan de Mooij]

Warp is now enabled by default on Nightly, after positive feedback
from users dogfooding it [0,1].

Here are just a few of the Talos/Raptor graphs showing improvements
when Warp landed:

- 20% on Win64 GDocs loadtime: https://mzl.la/3cp6dAs
- 13% on Android Reddit SpeedIndex: https://mzl.la/2RUWdp8
- 18% on pdfpaint: https://mzl.la/2HtXb9W
- 8% on tp6 JS memory: https://mzl.la/3j2VwGb
- 8% on damp (devtools perf): https://mzl.la/3kLbhSM

Please let us know if you notice any improvements or regressions.

Thanks,
The Warp team

[0] 
https://www.reddit.com/r/firefox/comments/itib6s/dogfooding_warp_on_nightly_new_js_jit_engine/
[1] 
https://www.reddit.com/r/firefox/comments/iy2036/nightly_is_finally_feeling_as_fast_as_chromium/

On Tue, Sep 15, 2020 at 2:57 PM Jan de Mooij  wrote:
>
> Hi all,
>
> The SpiderMonkey (JS) team has been working on a significant update to
> our JITs called WarpBuilder (or just Warp) [0,1]. Before we enable
> Warp by default in Nightly (hopefully next cycle in 83) we need your
> help dogfooding it.
>
> Warp improves performance by reducing the amount of internal type
> information that is tracked, optimizing for a broader spectrum of
> cases, and by leveraging the same CacheIR optimizations used by last
> year’s BaselineInterpreter work [2]. As a result, Warp has a much
> simpler design and improves responsiveness and page load performance
> significantly (we're seeing 5-15% improvements on many visual metrics
> tests). Speedometer is about 10% faster with Warp. The JS engine also
> uses less memory when Warp is enabled.
>
> To enable Warp in Nightly:
>
> 1. Update to a recent Nightly
> 2. Go to about:config and set the "javascript.options.warp" pref to true
> 3. Restart the browser
>
> We're especially interested in stability issues and real-world
> performance problems. Warp is currently slower on various synthetic JS
> benchmarks such as Octane (which we will continue investigating in the
> coming months) but should perform well on web content.
>
> If you find any issues, please file bugs blocking:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1613592
>
> If you notice any improvements, we'd love to hear about those too.
>
> Finally, we want to thank our amazing contributors André Bargull and
> Tom Schuster for their help implementing and porting many
> optimizations.
>
> Turning Warp on is only our first step, and we expect to see a lot of
> new optimization work over the next year as we build on this. We are
> excited for what the future holds here.
>
> Thanks!
> The Warp team
>
> [0] WarpBuilder still utilizes the backend of IonMonkey so we don't
> feel it has earned the WarpMonkey name just yet.
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1613592
> [2] 
> https://hacks.mozilla.org/2019/08/the-baseline-interpreter-a-faster-js-interpreter-in-firefox-70/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Dogfooding Warp

[Jan de Mooij]

Hi all,

The SpiderMonkey (JS) team has been working on a significant update to
our JITs called WarpBuilder (or just Warp) [0,1]. Before we enable
Warp by default in Nightly (hopefully next cycle in 83) we need your
help dogfooding it.

Warp improves performance by reducing the amount of internal type
information that is tracked, optimizing for a broader spectrum of
cases, and by leveraging the same CacheIR optimizations used by last
year’s BaselineInterpreter work [2]. As a result, Warp has a much
simpler design and improves responsiveness and page load performance
significantly (we're seeing 5-15% improvements on many visual metrics
tests). Speedometer is about 10% faster with Warp. The JS engine also
uses less memory when Warp is enabled.

To enable Warp in Nightly:

1. Update to a recent Nightly
2. Go to about:config and set the "javascript.options.warp" pref to true
3. Restart the browser

We're especially interested in stability issues and real-world
performance problems. Warp is currently slower on various synthetic JS
benchmarks such as Octane (which we will continue investigating in the
coming months) but should perform well on web content.

If you find any issues, please file bugs blocking:

https://bugzilla.mozilla.org/show_bug.cgi?id=1613592

If you notice any improvements, we'd love to hear about those too.

Finally, we want to thank our amazing contributors André Bargull and
Tom Schuster for their help implementing and porting many
optimizations.

Turning Warp on is only our first step, and we expect to see a lot of
new optimization work over the next year as we build on this. We are
excited for what the future holds here.

Thanks!
The Warp team

[0] WarpBuilder still utilizes the backend of IonMonkey so we don't
feel it has earned the WarpMonkey name just yet.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1613592
[2] 
https://hacks.mozilla.org/2019/08/the-baseline-interpreter-a-faster-js-interpreter-in-firefox-70/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

SpiderMonkey Newsletter #6

[Jan de Mooij]

(This newsletter is also available on our blog
.)

SpiderMonkey is the JavaScript engine used in Mozilla Firefox. This
newsletter gives an overview of the JavaScript and WebAssembly work we’ve
done as part of the Firefox 80 and 81 Nightly release cycles. If you like
these newsletters, you may also enjoy Yulia’s Compiler Compiler live stream
.

With the recent changes at Mozilla, some may be worried about what this
means for SpiderMonkey. The team continues to remain strong, supported and
is excited to show off a lot of cool things this year and into the future.
JavaScript ‍♀️ New features Firefox 80

   - Ted added 
   support for the export * as ns from “module” syntax in modules proposal
   .

In progress

   - Matthew implemented
    private class
   fields
   
,
   behind a pref. He also added
    support for
   adding private class fields to proxies.
   - Adam implemented 
   support for private methods and accessors
   , behind a pref.
   - Adam added  more
    Iterator helper
    methods.
   - Jeff landed 
   more changes for ReadableStream pipeTo/pipeThrough.
   - André implemented
   
   Intl.DateTimeFormat.prototype.formatRange and formatRangeToParts.
   - Yulia started 
   implementing Top-level await
   .

️ Garbage Collection

   - Jon moved  more
   decommit code to the background thread.
   - Jon added  prefs
   and improved heuristics for the number of helper threads doing GC work.
   - Yoshi added  GC
   sub-categories to the profiler.
   - Paul removed 
   some unused GC telemetry code to improve memory usage.
   - Jon enabled 
   compacting for ObjectGroups.
   - Yoshi fixed 
   shutdown GCs to not start compression tasks.

❇️ Stencil

Stencil  is our
project to create an explicit interface between the frontend (parser,
bytecode emitter) and the rest of the VM, decoupling those components. This
lets us improve performance, simplify a lot of code and improve bytecode
caching. It also makes it possible to rewrite our frontend in Rust (see
SmooshMonkey item below).

We expect to switch 
the frontend to use ParserAtoms in the next Nightly cycle (Firefox 82). At
that point the frontend will work without doing any GC allocations and will
be more independent from the rest of the engine, unblocking further
(performance) improvements.

   - Arai decoupled 
   Stencil structures more from the frontend data structures.
   - Ted made  module
   parsing work with Stencils and without allocating GC things.
   - Ted deferred  GC
   allocation of ScriptSourceObject.
   - Ted cleaned  up
   scope/environment handling.
   - Arai added  a
   dumpStencil(code) function to the JS shell to print the Stencil data
   structures.
   - Kannan landed 
   more  changes
    preparing for the
   switch to ParserAtom.

 SmooshMonkey

SmooshMonkey  is our
project to reimplement the frontend in a safe language (Rust) and will make
it easier to implement new features and improve long-term maintainability
of the code base.

   - Arai hooked up 
   the output of the Rust frontend to Stencil’s function data structures.

 WarpBuilder

WarpBuilder 

SpiderMonkey Newsletter #5

[Jan de Mooij]

(This newsletter is also available on our blog
.)

SpiderMonkey is the JavaScript engine used in Mozilla Firefox. This
newsletter gives an overview of the JavaScript and WebAssembly work we’ve
done as part of the Firefox 78 and 79 Nightly release cycles.

If you like these newsletters, you may also enjoy Yulia’s weekly Compiler
Compiler live stream
, a
guided tour of what it is like to work on SpiderMonkey and improve spec
compliance.
JavaScript  New features Firefox 78

   - Iain’s regular expression engine work (see below) resulted in support
   for:
  - dotAll flag 
  - Named capture groups
  
  - Unicode property escapes
  
  - Lookbehind assertions
  
   - André enabled 
   Intl.ListFormat  by
   default.
   - André enabled 
   the Unified NumberFormat API
    by default.

Firefox 79

   - Jon enabled  WeakRef
   and FinalizationRegistry  by
   default.
   - André enabled 
   the new logical assignment operators
    (&&=, ||=, ??=)
   by default.
   - Jason enabled
 Promise.any
   and AggregateError  by
   default.
   - André implemented
    the dateStyle and
   timeStyle options 
   on Intl.DateTimeFormat.

‍♀️ Feature work

   - Matthew has started
    implementing private
   class fields .
   - Adam is implementing
    the Iterator
   Helpers  proposal.
   - Yulia started 
   implementing the Top-level Await
    proposal.
   - Jeff landed 
   more changes for ReadableStream pipeTo/pipeThrough support.
   - Tom defined 
   Symbol.toStringTag
   

   properties on DOM prototype objects and then removed
    the
   (non-standard) code for Object.prototype.toString where it used the
   internal JSClass name.
   - André changed 
   Atomics methods to work on non-shared ArrayBuffers.
   - André implemented
    the
   Intl.DisplayNames 
   proposal (disabled by default).

⏩ Regular Expression engine update

   - Iain fixed the last blockers and enabled
    the new engine by
   default.
   - Iain then implemented
    support for named
   capture groups and added
    a fuzzing target
   for differential testing of interpreted vs compiled code with libfuzzer.
   -

   Finally, Iain removed
    the old engine in
   Firefox 79 and tidied up the code.

   See the Mozilla Hacks blog post
   
   for more details.

️ Garbage Collection

   - Steve enabled 
   incremental WeakMap marking, a big change to help reduce GC pauses.
   - Steve landed 
   changes to de-duplicate strings during nursery GC, based on work done by GC
   intern Krystal Yang and then rebased by Thinker Li.
   - Jon added  a
   header to nursery-allocated cells and used this
    to simplify code.
   - Steve created  a
   GC micro-benchmark suite that can be used to compare GC 

SpiderMonkey Newsletter #4

[Jan de Mooij]

(This newsletter is also available on our blog
.)

SpiderMonkey is the JavaScript engine used in Mozilla Firefox. This
newsletter gives an overview of the JavaScript and WebAssembly work we’ve
done as part of the Firefox 76 and 77 Nightly cycles.
JavaScript  New contributors

   - Kousuke Takaki fixed bug 1601734
   , tidying up some
   naming.
   - Tuan fixed bug 1566116
   , deleting dead
   code.

 New features

   - *Firefox 76*: André updated
    ICU to version 66
   with support for Unicode 13 .
   - *Firefox 76*: numberingSystem and calendar for Intl objects can now be
   set through options
   .
   - *Firefox 77*: String.prototype.replaceAll is no longer Nightly-only
    and will ride the
   trains to release.
   - *Firefox 77 (Nightly-only)*: André implemented
    the Logical
   Assignment Operators
    proposal (adds
   the ||=, &&=, ??= operators).

️ Garbage Collection

   - Jon made  various
    changes
    to GC heuristics
   to avoid non-incremental GCs.
   - Steve landed 
   and enabled 
   incremental marking for WeakMaps, a big change that will help reduce long
   GC slices, but to reduce risk this was backed out for Firefox 77. We’re
   hoping this sticks in Firefox 78!
   - Jon made 
   tracing of ‘auto rooters’ faster. He also noticed regressions on Linux64
   from parallel unmarking and made
    performance
   improvements to fix that.
   - Jon optimized 
   tracing of certain DOM objects in Firefox by allowing per-Zone tracing
   instead of tracing all of them.
   - Jon fixed various OOM (out of memory) crashes by adding
    memory accounting
   for malloc buffers associated with nursery cells and by improving
    GC malloc
   triggers.
   - Steve updated 
   the static analysis for rooting hazards to GCC 9.

⏩ Regular expression engine update

Iain finished 
implementing  the
SpiderMonkey shims and JIT support
 for the new regular
expression engine and is planning to land these in the FF 78 cycle to switch
to  the new engine in
Nightly! This will bring

support for lookbehind assertions, the dotAll flag and unicode escape
sequences.

Iain has also started working on supporting named groups
 and match indices
.
 JSScript/LazyScript unification

With all the groundwork in place (see previous newsletters), Ted was able
to unify  JSScript
and LazyScript! Functions no longer require a separate LazyScript and
JSScript and delazification and relazification now happen in-place.

He then removed  the
LazyScript type completely and landed
 various follow-up
changes to take advantage of the new system.
❇️ Stencil

Stencil  is our
project to create an interface between the frontend (parser, bytecode
emitter) and the rest of the VM, decoupling those components. This lets us
improve performance, simplify a lot of code and improve bytecode caching.
It also makes it possible to rewrite our frontend in Rust (see SmooshMonkey
item below).

The team is making good progress:

   - Caroline split 
   the script flags into multiple categories so it’s easier to assert
   correctness and reason about them. She also
    made
    various
   

SpiderMonkey Newsletter #3

[Jan de Mooij]

(This newsletter is also available on our blog
.)
JavaScript  New contributors

   - Rob Rico tidied up
    some code in the
   parser

 New features

   - Yulia implemented
    the optional
   chaining (?.) operator (Firefox 74)
   - André implemented
    public static
   class fields (Firefox 75)
   - André implemented
    the Intl.Locale
   proposal (Firefox 75)

 SmooshMonkeyThe previous newsletter

introduced Visage, a new JavaScript frontend
 we’re working on that’s
written in Rust. Visage has since been renamed to SmooshMonkey, a name
that’s known and well accepted
 by the JavaScript
community (#SmooshGate). After a dinner and discussions with project
members, it got authoritatively renamed by speaking about it

at the All-Hands.

The team is making good progress
:

   - SmooshMonkey has been integrated in Gecko
    behind a
   configure flag and a runtime flag.
   - Passes 100%
   
   of SpiderMonkey tests (falling back on SpiderMonkey’s current parser for
   non-implemented features).
   - Added stats about the project using Github CI.
   - The bytecode emitter has been improved to prevent generating bytecode
   which might have undefined behaviour.
   - There’s a new parser generator
    to
support context-dependent
   aspects 
   of the JavaScript grammar instead of exploding the number of states of the
   equivalent context-free grammar.

❇️ Stencil

Progress on Project Stencil
 is continuing. Huge
thanks to André for helping knock three
 blocking
 bugs
 off in quick
succession!

Matthew landed many patches to clean up
 our compilation
management data structures. He also added
 a SourceExtent
structure to store source information and changed the frontend to always
defer  supported GC
allocations.

Kannan is working on 
removing GC atom allocation from the frontend. The frontend uses atoms in
many places and to make the frontend GC-free we need a different strategy
for that.

Caroline is working at
 cleaning up the
flags used throughout the frontend, to unify BaseScript::ImmutableFlags,
CompileOptions, and FunctionBox flags into one representation.
 JSScript/LazyScript unification

The JSScript/LazyScript unification
 is nearing
completion. Ted has landed patches for Firefox 75 to use the same GC
TraceKind  for
LazyScript and JSScript and after that was able to merge
 the GC arenas. The
is-lazy state has been moved
 from JSFunction to
BaseScript.

The next big step is delazifying/relazifying scripts in place
 so that we never
have to keep both a JSScript and a LazyScript for a function.
 WarpBuilder

Ion, our optimizing JIT, currently relies on a global Type Inference (TI)
mechanism. Ion and TI have a number of shortcomings
 so we’re
experimenting with a much simpler MIR builder for Ion that’s based on
Baseline ICs (CacheIR) instead of TI. If this works out it will let us
delete some of our most complicated code, allow us to do more work
off-thread, and result in memory usage reductions and performance
improvements across the engine.

The past weeks Jan landed patches preparing
 for this
 and added
 a very primitive
WarpBuilder implementation 

SpiderMonkey Newsletter #2

[Jan de Mooij]

(This newsletter is also available on our blog
<https://spidermonkey.dev/blog/2020/01/10/newsletter-2.html>.)

Happy new year from the SpiderMonkey team!

Heads up: the next newsletter will likely cover both Firefox 74 and Firefox
75 due to the shorter release cycles this year.
JavaScript New features

   - The relatedYear field type for
   Intl.DateTimeFormat.prototype.formatToParts is now part of the spec so
   André Bargull made it
   <https://bugzilla.mozilla.org/show_bug.cgi?id=1591664> ride the trains.

Project Visage

Project Visage is a project to write a new frontend (parser and bytecode
emitter) for JavaScript in Rust that’s more maintainable, modular,
efficient, and secure than the current frontend. The team (Jason Orendorff,
Nicolas Pierron, Tooru Fujisawa, Yulia Startsev) is currently experimenting
<https://github.com/mozilla-spidermonkey/jsparagus> with a parser generator
that generates a custom LR parser.

There’s a fork of mozilla-central
<https://github.com/mozilla-spidermonkey/rust-frontend> where passing
--rust-frontend to the shell makes it try the new frontend, falling back on
the C++ frontend for scripts it can’t handle (currently almost everything).
LibFuzzer is used as a way to identify issues where the new parser accepts
inputs which are currently rejected by the current parser.

Jason also improved <https://bugzilla.mozilla.org/show_bug.cgi?id=1602530>
most of our bytecode documentation
<https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals/Bytecode>
.

(Jason pronounces it “VIZZ-udge”, like the English word, but you can say
whatever you want.)
JSScript/LazyScript unification

Ted Campbell fixed <https://bugzilla.mozilla.org/show_bug.cgi?id=1600705>
the parser to avoid saving trivial data between syntax parsing and the
eventual delazification. This saves memory and brings us closer to being
able to reconstruct a lazy script directly from its non-lazy version.

The js::BaseScript
<https://searchfox.org/mozilla-central/rev/be7d1f2d52dd9474ca2df145190a817614c924e4/js/src/vm/JSScript.h#1986>
type now contains the fields it needed to represent lazy and non-lazy
scripts. This is an important milestone on the path to unifying JSScript
and LazyScript.
Project Stencil

As the GC-free parser work continues, Project Stencil aims to define a
meaningful data format for the parser to generate. This paves the way to
integrating a new frontend (Visage) and allows us to modernize the bytecode
caches and improve page-load performance. We call it ‘stencil’ because this
data structure is the template from which the VM’s JSScript will be
instantiated.

   - Matthew Gaudet started fuzzing the deferred allocation path in the
   front end. The hope is that we will enable this code path by default early
   in the Firefox 74 cycle. The end goal of turning this on by default is to
   avoid having to maintain two allocation paths indefinitely.
   - The LazyScript unification work continues to simplify (and clarify)
   the semantics of internal script flags that the parser must generate. These
   flags will become part of the stencil data structures.

Regular expression engine update

Iain Ireland is writing a shim layer to enable Irregexp, V8’s regexp
engine, to be embedded in SpiderMonkey with minimal changes relative to
upstream. He is currently working on rewriting the existing regular
expression code to call the new engine.
Bytecode and IonBuilder simplifications

The previous newsletter mentioned some large IonBuilder code
simplifications landing in Firefox 72. This cycle Jan de Mooij changed
<https://bugzilla.mozilla.org/show_bug.cgi?id=1598548> all loops to have
the same bytecode structure so IonBuilder can use the same code for all of
them. This also allowed us to remove
<https://bugzilla.mozilla.org/show_bug.cgi?id=1601599> more source notes
and JIT compilation no longer has to look up any source notes.

These changes help the new frontend because it’s now easier to generate
correct bytecode and also laid the groundwork for more Ion cleanup work
this year. Finally, it ended up fixing some performance cliffs: yield*
expressions
<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/yield*>,
for example, can be at least 5x faster
<https://bugzilla.mozilla.org/show_bug.cgi?id=1601072#c4>.
toSource/uneval removal

Tom Schuster is investigating
<https://bugzilla.mozilla.org/show_bug.cgi?id=1565170#c5> removing the
non-standard toSource and uneval functions. This requires fixing a lot of
code and tests in Firefox
<https://bugzilla.mozilla.org/show_bug.cgi?id=1605854> so as a first step
we may do this only for content code. André Bargull helped out
<https://bugzilla.mozilla.org/show_bug.cgi?id=1565001> by fixing
SpiderMonkey tests to stop using these functions.
Debugger

Logan Smyth rewrote <https://bugzilla.mozilla.org/show_bug.cgi?id=1602699>
deb

Re: PSA: You can use UTF8String from WebIDL

[Jan de Mooij]

On Mon, Jan 6, 2020 at 2:51 AM Emilio Cobos Álvarez 
wrote:

> If it's not, it could be optimized teaching JSStrings to store UTF-8
> instead of / on top of Latin1 or such, or returning more information
> from the callee, but I don't know how easy would be the first (IIRC
> we're out of JSString bits), and how worth it would be the second.
> Feedback here from JS engine hackers would be much appreciated.
>

Supporting UTF8 JSStrings natively would be quite a lot of work. I added
Latin1 strings a few years ago but Latin1 is a bit simpler than UTF8
because most algorithms could be templatized to work with either char type.
If most of your UTF8 strings are (7-bit) ASCII, it might make sense
short-term to use a Latin1 external string to avoid copies.

One possible approach would be to treat UTF8 JSStrings somewhat similar to
ropes: initially most places working with JSString characters would end up
converting from UTF8 to Latin1/TwoByte but after that we could
(incrementally) optimize these functions to work with UTF8 strings directly
where possible.

Jan

___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: SpiderMonkey Newsletter #1

[Jan de Mooij]

On Thu, Dec 5, 2019 at 8:34 PM Dirkjan Ochtman  wrote:

> On Thu, Dec 5, 2019 at 7:08 PM Jan de Mooij  wrote:
>
>> (This newsletter is also available on our blog
>> <https://spidermonkey.dev/blog/2019/12/04/newsletter-1.html>.)
>>
>
> Does this mean http://blog.mozilla.org/javascript will not be used
> anymore?
>

Good question. We're trying to have one place where we can put
SpiderMonkey-specific content (API docs, build docs, embedding info, blog
posts) going forward, a bit similar to https://geckoview.dev and
https://mozac.org for example. I'll see if we can add a post to the old
blog to forward readers to spidermonkey.dev

Thanks,
Jan


>
> Kind regards,
>
> Dirkjan
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Upcoming changes to hg.mozilla.org access

[Jan de Mooij]

On Mon, Nov 4, 2019 at 8:36 AM David Teller  wrote:

> For what it's worth, when I last tried, I couldn't even `moz-phab
> submit` a self-reviewed patch. I had to arbitrarily pick another
> reviewer for a patch that was not meant for landing (it was a
> demonstration of a reproducible bug in phabricator, but that's another
> story).
>

Yes, moz-phab used to require a reviewer, but that was changed a year ago.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1482216

Jan

On 03/11/2019 11:14, Emilio Cobos Álvarez wrote:
> > On 11/2/19 12:53 PM, Andreas Tolfsen wrote:
> >> Documentation changes have historically been well served by a “wiki
> >> editing”/micro adjustments approach.  I wonder if there is anything
> >> we can do with Phabricator to ease review requirements for documentation
> >> changes from peers?
> >
> > I think you can land patches without review even with Lando. I
> > personally think that's acceptable for typo fixes / documentation
> > updates / etc.
> >
> > It's certainly a few more clicks than `git push` / `hg push` though.
> >
> >  -- Emilio
> >
> >
> >> ___
> >> dev-platform mailing list
> >> dev-platform@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-platform
> >>
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Passing UniquePtr by value is more expensive than by rref

[Jan de Mooij]

On Mon, Oct 14, 2019 at 8:05 AM Gerald Squelart 
wrote:

> A quick searchfox shows a few hundred by-value unique pointer's, we
> may want to look into these.
> Though I guess it's a trade-off between the expressiveness of by-value
> ("I'm stealing your value for sure") vs the more efficient but less obvious
> by-rref ("Maybe I'll take your value").
>

For what it's worth, this is what our documentation recommends [0]: "To
unconditionally transfer ownership of a UniquePtr into a method, use a
|UniquePtr| argument. To conditionally transfer ownership of a resource
into a method, should the method want it, use a |UniquePtr&&| argument."
I've definitely passed UniquePtr by value a number of times based on this
comment.

Jan

[0]
https://searchfox.org/mozilla-central/rev/6866d3a650c826f1cabd123663e84b95ee743701/mfbt/UniquePtr.h#179-186


> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: JS testing functions and compartments in mochitest-plain

[Jan de Mooij]

On Mon, Aug 26, 2019 at 12:25 PM Henri Sivonen  wrote:

> Thanks. Since SpecialPowers doesn't exist in xpcshell tests, is there
> another way to reach JS testing functions from there?
>

I think just Cu.getJSTestingFunctions() should work.

Jan


>
> --
> Henri Sivonen
> hsivo...@mozilla.com
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: JS testing functions and compartments in mochitest-plain

[Jan de Mooij]

On Mon, Aug 26, 2019 at 9:02 AM Henri Sivonen  wrote:

> In what type of test does
> SpecialPowers.Cu.getJSTestingFunctions().newRope() actually return a
> rope within the calling compartment such that passing the rope to a
> WebIDL API really makes the rope enter the WebIDL bindings instead of
> getting intercepted by a cross-compartment wrapper first?
>

An xpcshell test or mochitest-chrome is probably easiest.. Or a system
Sandbox/evalInSandbox but that becomes more complicated. Strings are copied
across zone boundaries so any global in the system zone should work. You
can use the isSameCompartment JS testing function to test/assert the
following is true in your test:
testingFunctions.isSameCompartment(testingFunctions.newRope, this)
(same-compartment is a stronger invariant than same-zone but for system
compartments it should be fine).


> Alternatively: What kind of string lengths should I use with normal JS
> string concatenation to be sure that I get a rope instead of the right
> operand getting copied into an extensible left operand?
>

js::ConcatStrings creates a rope if both sides have length > 0 and the
result doesn't fit in a JSFatInlineString (limits there are 11 and 23 for
Latin1 vs TwoByte chars). The extensible-string optimization applies to
rope flattening (we still create a rope first in that case).

Hope this helps,
Jan


>
> --
> Henri Sivonen
> hsivo...@mozilla.com
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: clang version on tryserver?

[Jan de Mooij]

On Tue, Jul 30, 2019 at 1:51 PM ISHIKAWA,chiaki 
wrote:

>nsresult rv2
>  = NS_NewBufferedOutputStream(getter_AddRefs(mCopyState->m_fileStream),
> mCopyState->m_fileStream.forget(),  <=== It seems this can be nullptr in
> clang-8 version???
>   64 * 1024 );
>

This looks like it could be caused by Clang evaluating your arguments in a
different order from GCC (see also [0]). If Clang evaluates left-to-right,
that getter_AddRefs might null out your m_fileStream before we evaluate the
m_fileStream.forget().

Hope this helps,
Jan

[0]
https://stackoverflow.com/questions/15440833/g-vs-intel-clang-argument-passing-order

Chiaki
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Major ChromeUtils.import() API change

[Jan de Mooij]

On Tue, Jan 29, 2019 at 5:51 AM Kris Maglione  wrote:

> To begin with, the weirdness of our JSM scopes makes a fair amount of our
> system code un-JITtable, which should be enough on its own.


In case people are wondering: un-JITtable applies to Ion, the optimizing
JIT. The Baseline JIT is able to compile all chrome code. That said,
Baseline is also affected by the performance issues here because our inline
caches don't optimize the 'special' environment objects that are currently
used for JSMs, so accessing global variables is much slower than in content
code.

Many thanks to Kris and others for working on this. Making our chrome and
content environments more similar means chrome code will benefit from all
the optimization work we do for content code and ES6 modules.

Jan


> -Kris
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds

[Jan de Mooij]

On Fri, Jan 18, 2019 at 10:36 PM Joel Maher  wrote:

> Are there any concerns with this latest proposal?
>

This proposal sounds great to me. Thank you!

Jan

On Thu, Jan 17, 2019 at 12:52 PM Jan de Mooij  wrote:
>
>> Hi Joel,
>>
>> Can you say more about this point in your original email: "3) This will
>> reduce the jobs (about 16%) we run which in turn reduces, cpu time, money
>> spent, turnaround time, intermittents, complexity of the taskgraph." It
>> seems to me that if we remove non-PGO opt builds even on Try, we might use
>> more cpu time because there are so many Try pushes requesting opt builds.
>> Do we have data on this?
>>
>> Thanks,
>> Jan
>>
>> On Thu, Jan 17, 2019 at 5:45 PM jmaher  wrote:
>>
>>> Following up on this, thanks to Chris we have fast artifact builds for
>>> PGO, so the time to develop and use try server is in parity with current
>>> opt solutions for many cases (front end development, most bisection cases).
>>>
>>> I have also looked in depth at what the impact on the integration
>>> branches would be.  In the data set from July-December (H2 2018) there were
>>> 11 instances of tests that we originally only scheduled in the OPT config
>>> and we didn't have PGO or Debug test jobs to point out the regression (this
>>> is due to scheduling choices).  Worse case scenario is finding the
>>> regression on PGO up to 1 hour later 11 times or roughly 2x/month.
>>> Backfilling to find the offending patch as we do now 24% of the time would
>>> be similar time.  In fact running the OPT jobs on Debug instead would
>>> result in same time for all 11 instances (due to more chunks on debug and
>>> similar runtimes).  In short, little to no impact.
>>>
>>> Lastly there was a pending question about talos.  There is an edge case
>>> where we can see a regression on talos that is PGO, but it is unrelated to
>>> the code and just a side effect of how PGO works.  I looked into that in
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1514829.  I found that if
>>> we didn't get opt alerts that we would not have missed any regressions.
>>> Furthermore, for the regressions, for the ones that were pgo only
>>> regressions (very rare) there were many other regressions at the same time
>>> (say a build change, or test change, etc.) and usually these were accepted
>>> changes, backed out, or investigated on a different test or platform.  In
>>> the past when we have determined a regression is a PGO artifact we have
>>> resolved it as WONTFIX and moved on.
>>>
>>> Given this summary, I feel that most concerns around removing testing
>>> for OPT are addressed.  I would also like to extend the proposal to remove
>>> the OPT builds since no unit or perf tests would run on there.
>>>
>>> As my original timeline is not realistic, I would like to see if there
>>> are comments until next Wednesday- January 23rd, then I can follow up on
>>> remaining issues or work towards ensuring we start the process of making
>>> this happen and what the right timeline is.
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds

[Jan de Mooij]

Hi Joel,

Can you say more about this point in your original email: "3) This will
reduce the jobs (about 16%) we run which in turn reduces, cpu time, money
spent, turnaround time, intermittents, complexity of the taskgraph." It
seems to me that if we remove non-PGO opt builds even on Try, we might use
more cpu time because there are so many Try pushes requesting opt builds.
Do we have data on this?

Thanks,
Jan

On Thu, Jan 17, 2019 at 5:45 PM jmaher  wrote:

> Following up on this, thanks to Chris we have fast artifact builds for
> PGO, so the time to develop and use try server is in parity with current
> opt solutions for many cases (front end development, most bisection cases).
>
> I have also looked in depth at what the impact on the integration branches
> would be.  In the data set from July-December (H2 2018) there were 11
> instances of tests that we originally only scheduled in the OPT config and
> we didn't have PGO or Debug test jobs to point out the regression (this is
> due to scheduling choices).  Worse case scenario is finding the regression
> on PGO up to 1 hour later 11 times or roughly 2x/month.  Backfilling to
> find the offending patch as we do now 24% of the time would be similar
> time.  In fact running the OPT jobs on Debug instead would result in same
> time for all 11 instances (due to more chunks on debug and similar
> runtimes).  In short, little to no impact.
>
> Lastly there was a pending question about talos.  There is an edge case
> where we can see a regression on talos that is PGO, but it is unrelated to
> the code and just a side effect of how PGO works.  I looked into that in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1514829.  I found that if we
> didn't get opt alerts that we would not have missed any regressions.
> Furthermore, for the regressions, for the ones that were pgo only
> regressions (very rare) there were many other regressions at the same time
> (say a build change, or test change, etc.) and usually these were accepted
> changes, backed out, or investigated on a different test or platform.  In
> the past when we have determined a regression is a PGO artifact we have
> resolved it as WONTFIX and moved on.
>
> Given this summary, I feel that most concerns around removing testing for
> OPT are addressed.  I would also like to extend the proposal to remove the
> OPT builds since no unit or perf tests would run on there.
>
> As my original timeline is not realistic, I would like to see if there are
> comments until next Wednesday- January 23rd, then I can follow up on
> remaining issues or work towards ensuring we start the process of making
> this happen and what the right timeline is.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds

[Jan de Mooij]

On Thu, Jan 3, 2019 at 7:22 PM Steve Fink  wrote:

> I get
> quite a bit of value out of the resulting faster hack-try-debug cycles;
> I would imagine it to be at least as useful to have a turnaround time of
> 1 hour for opt vs 2 hours for pgo.
>

+1. The past week I've been Try-debugging (1) an intermittent Talos orange
(affected only Win64 opt and pgo, bug 1516679) and (2) an intermittent dt8
orange (affected only Win32 opt and pgo, bug 1516967). This was a pretty
annoying process, but pgo builds would have made this much worse. I'd
really appreciate it if we considered keeping "opt" as an optional
configuration for these use cases - it will save some people a lot of time.

Thanks,
Jan



>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: Compartments will soon contain multiple global objects

[Jan de Mooij]

The JS engine now supports allocating multiple global objects (also known
as "realms") in a single compartment [0]. We are working on using this
mechanism for our chrome code (one compartment for most of our
system-principal sandboxes [1] and windows [2]). I'm hoping that part will
land relatively soon. After that we want to enable this for same-origin
content globals (like iframes) as well. This is the main goal of this work,
but it depends on some architectural changes that are still in flight.

We are doing this to reduce cross-compartment wrapper overhead: globals
within a compartment can access each other directly, without any wrapper
overhead, and they can share wrappers into other compartments. Initial
results are promising; we are seeing performance improvements on various
talos tests and some memory usage improvements as well.

What this means is that globals are no longer guaranteed to have their own
compartment. Instead of entering a compartment (JSAutoCompartment), code
should now enter a global/realm (JSAutoRealm). Note that JSAutoRealm cannot
be used with cross-compartment wrappers (there's a diagnostic assert for
this, because cross-compartment wrappers are now shared by all realms in
the compartment, so entering a wrapper's realm is kind of meaningless).

Please keep this in mind when writing (test) code. Let me know if there are
any questions or concerns.

Thanks,
Jan

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1357862
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1512029
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1514210
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: [implicit_jscontext] XPIDL methods/attributes can now be implemented in JS

[Jan de Mooij]

Hi all,

It's now possible to have JS implementations of an XPIDL method/attribute
marked as [implicit_jscontext]. This used to throw an exception because the
xptcall stubs didn't support it. Bug 1475699 [0] fixes the stubs to skip
the implicit context argument.

This is useful when you have both JS and C++ implementations of an IDL
method/attribute and you want the C++ implementations to have the
JSContext* argument.

Jan

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1475699
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Gecko-visible Latin1 analog of JS_NewUCString()

[Jan de Mooij]

I don't think so. We could add JS_New(Latin1)String that takes Latin1Char*
instead of char16_t* (like JS_NewUCString, it can just forward to
js::NewString).

Hope this helps,
Jan

On Tue, Feb 6, 2018 at 3:36 PM, Henri Sivonen  wrote:

> Does SpiderMonkey expose a Latin1 analog of JS_NewUCString() for Gecko to
> call?
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Re-visiting the DOM tree depth limit in layout

[Jan de Mooij]

On Thu, Sep 14, 2017 at 8:23 AM, Henri Sivonen  wrote:

> Do I understand correctly that this is an address space issue only and
> Windows doesn't actually physically map the pages belonging to the
> stack until they are written to? That is, do I understand correctly
> that there's no obstacle for growing the maximum stack size on 64-bit
> Windows to the kind of numbers that Mac and Linux already have?
>

Correct, Windows reserves stack pages but does not commit them until the
guard page is touched.


> Is there a reason why a larger stack size is OK on 32-bit Linux but
> wouldn't be OK on 32-bit Windows?
>

One difference is that Linux does not reserve stack pages (if the heap
grows big it can use unused stack pages).


> The failure mode of parts of email text silently going missing when
> reading HTML email on a webmail app is *really* bad, so I'd like to
> get it fixed in 57 instead of waiting for a task that touches many
> more places getting completed further in the future.
>

We could get this fixed, then spend a few minutes in VMMap to check whether
there are any long-lived beckground threads with excessive stack sizes that
we could easily fix. I don't have a strong opinion on this btw - I just
wanted to point out that it affects threads other than the main thread.

Jan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Re-visiting the DOM tree depth limit in layout

[Jan de Mooij]

On Wed, Sep 13, 2017 at 10:44 AM, Henri Sivonen 
wrote:

> 3) Increase the run-time stack size on Windows such that 1026-deep
> display: table-cell doesn't overflow the stack.
>

On Windows, threads that are created without an explicit stack size also
use the executable's stack size. So increasing our stack size will also
affect a bunch of other threads and we risk an increase in virtual memory
OOMs on Win32. I filed bug 1257522 [0] two years ago to pass an explicit
stack size for a number of background threads we create in Gecko, it would
be nice to fix that first.

Jan

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1257522
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Re-visiting the DOM tree depth limit in layout

[Jan de Mooij]

On Mon, Sep 11, 2017 at 5:27 PM,  wrote:

> On Monday, September 11, 2017 at 1:41:43 PM UTC+2, Henri Sivonen wrote:
> > Can we ask Windows to give us more stack space?
> > --
> Don't know if it's possible to set it dynamically at runtime, but Visual
> Studio supports setting it at compile time (in linker options).
>

Yes, we already set the stack size to 2 MB on Win64 [0]. In case it helps,
in bug 1257234 I added some code to detect the main thread stack size on
Windows (for JS recursion limits).

Jan

[0]
http://searchfox.org/mozilla-central/rev/00fa5dacedb925022f53d025121f1a919508e7ce/config/config.mk#422



> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Overhead of returning a string from C++ to JS over WebIDL bindings

[Jan de Mooij]

On Fri, Jun 16, 2017 at 2:08 PM, Jan de Mooij <jdemo...@mozilla.com> wrote:

> Objects are already nursery allocated, so that's probably why ArrayBuffer
> is faster.
>

Sorry, I think ArrayBuffers are not nursery allocated right now, so
allocating a ton of them would also trigger major GCs.

Also note that we have an external string cache (see
ExternalStringCache::lookup), it compares either the char pointers or the
actual characters (if length <= 100). If we are returning the same strings
(same characters) all the time on this benchmark, you could try removing
that length check to see if it makes a difference.

Jan


>
> We create external strings (a JS string referencing a DOM string buffer)
> for the strings returned from DOM to JS and in my profiles I don't see us
> spending a lot of time on this. More than 70% of the time is in
> encoding_rs. It may be different for other parts of the benchmark - it
> would be nice to have a minimal testcase showing the problem.
>
> Hope this helps,
> Jan
>
> On Fri, Jun 16, 2017 at 1:22 PM, Henri Sivonen <hsivo...@hsivonen.fi>
> wrote:
>
>> I noticed a huge performance difference between
>> https://hsivonen.com/test/moz/encoding_bench_web/ and
>> https://github.com/hsivonen/encoding_bench/ . The former has the
>> overhead of JS bindings. The latter doesn't.
>>
>> On a 2009 Mac Mini (Core 2 Duo), in the case of English, the overhead
>> is over twice the time spent by encoding_rs in isolation, so the time
>> per iteration over triples!
>>
>> The snowman test indicates that this isn't caused by SpiderMonkey's
>> Latin1 space optimization.
>>
>> Safari performs better than Firefox, despite Safari using ICU (except
>> for UTF-8 and windows-1252) and ICU being slower than encoding_rs in
>> isolation on encoding_bench (tested on Linux). Also, looking at
>> Safari's UTF-8 and windows-1252 decoders, which I haven't had the time
>> to extract for isolated testing, and Safari's TextDecoder
>> implementation, there's no magic there (especially no magic compared
>> to the Blink fork of the UTF-8 and windows-1252 decoders).
>>
>> My hypothesis is that the JSC/WebKit overhead of returning a string
>> from C++ to JS is much lower than SpiderMonkey/Gecko overhead or the
>> V8/Blink overhead. (When encoding from string to ArrayBuffer, Safari
>> doesn't have the advantage, which is also suggestive of this not being
>> a matter of how GC happens relative to the timed runs.)
>>
>> Do we know why?
>>
>> --
>> Henri Sivonen
>> hsivo...@hsivonen.fi
>> https://hsivonen.fi/
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Overhead of returning a string from C++ to JS over WebIDL bindings

[Jan de Mooij]

I profiled this quickly and we're spending a lot of time in GC. Nursery
allocating strings (bug 903519) is going to help a lot here as it will make
both string allocation and GC much faster. Objects are already nursery
allocated, so that's probably why ArrayBuffer is faster.

We create external strings (a JS string referencing a DOM string buffer)
for the strings returned from DOM to JS and in my profiles I don't see us
spending a lot of time on this. More than 70% of the time is in
encoding_rs. It may be different for other parts of the benchmark - it
would be nice to have a minimal testcase showing the problem.

Hope this helps,
Jan

On Fri, Jun 16, 2017 at 1:22 PM, Henri Sivonen  wrote:

> I noticed a huge performance difference between
> https://hsivonen.com/test/moz/encoding_bench_web/ and
> https://github.com/hsivonen/encoding_bench/ . The former has the
> overhead of JS bindings. The latter doesn't.
>
> On a 2009 Mac Mini (Core 2 Duo), in the case of English, the overhead
> is over twice the time spent by encoding_rs in isolation, so the time
> per iteration over triples!
>
> The snowman test indicates that this isn't caused by SpiderMonkey's
> Latin1 space optimization.
>
> Safari performs better than Firefox, despite Safari using ICU (except
> for UTF-8 and windows-1252) and ICU being slower than encoding_rs in
> isolation on encoding_bench (tested on Linux). Also, looking at
> Safari's UTF-8 and windows-1252 decoders, which I haven't had the time
> to extract for isolated testing, and Safari's TextDecoder
> implementation, there's no magic there (especially no magic compared
> to the Blink fork of the UTF-8 and windows-1252 decoders).
>
> My hypothesis is that the JSC/WebKit overhead of returning a string
> from C++ to JS is much lower than SpiderMonkey/Gecko overhead or the
> V8/Blink overhead. (When encoding from string to ArrayBuffer, Safari
> doesn't have the advantage, which is also suggestive of this not being
> a matter of how GC happens relative to the timed runs.)
>
> Do we know why?
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Introducing mozilla::Result for better error handling

[Jan de Mooij]

On Thu, Jan 5, 2017 at 7:31 AM, Xidorn Quan  wrote:

> Probably it can add a constructor which accepts T&& and Move it down the
> chain.
>

Agreed. We didn't do this initially to keep things simple and because we
didn't need it, but if there's a good use case we should add move
constructors.

Jan


> - Xidorn
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Introducing mozilla::Result for better error handling

[Jan de Mooij]

On Tue, Dec 20, 2016 at 5:31 PM, Ehsan Akhgari 
wrote:

> Is there a
> potential for mistakes like for example caused by the error types being
> implicitly convertible to each other but the values changing their
> meanings upon the conversion (for example a bool error type getting
> converted to an int error type)?
>

Good point! I filed a bug to discuss/fix this,
https://bugzilla.mozilla.org/show_bug.cgi?id=1325062

Thanks.
Jan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Introducing mozilla::Result for better error handling

[Jan de Mooij]

Hi all,

A few weeks ago we added mozilla::Result to MFBT [0][1]. I was asked
to inform dev-platform about this, so here's a quick overview.
mozilla::Result is based on Rust's Result type [2]. It contains
either a success value of type V or an error value of type E. For example,
a function Foo that returns an `int` on success or some `Error` (enum,
pointer, etc) on failure, would have this signature:

  Result Foo();

mozilla::Ok is an empty struct that can be used when a function doesn't
return anything on success:

  Result Bar() { ... return Ok(); }

The MOZ_TRY(expr) macro is similar to Rust's try! macro: if `expr` is an
error it propagates it to the caller, else it continues:

  Result Baz() { MOZ_TRY(Bar()); ... }

There's also a MOZ_TRY_VAR macro that can be used when you want to store
the return value on success. Result has isOk(), isErr(), unwrapOk(),
unwrapErr() methods that do what you'd expect. It also has the
MOZ_MUST_USE_TYPE annotation, so the static analysis builds will complain
if you ignore the return value of a function that returns Result.

Internally, Result uses mozilla::Variant, but there are some cases that can
be stored more efficiently. For instance, Result just stores an
Error* pointer and Ok is represented as nullptr. This is more efficient and
will also make it easier to call functions that return Result from JIT
code. The documentation [3] has more info.

The long-term plan is to use Result in SpiderMonkey, to simplify our
error/OOM handling [4][5].

Many thanks to Jason Orendorff (jorendorff) for doing most of the work by
writing the initial Result patches, and to Jeff Walden (Waldo) for his
thorough code reviews.

Jan

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1283562
[1] https://searchfox.org/mozilla-central/source/mfbt/Result.h
[2] https://doc.rust-lang.org/std/result/
[3]
https://searchfox.org/mozilla-central/rev/cc2a84852bd4e6f6d8d4d5b17b8382bb5d005749/mfbt/Result.h#148-158
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1277368
[5] https://searchfox.org/mozilla-central/source/js/public/Result.h
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Requiring SSE2 on all 32-bit x86 OSs (was: Re: Reverting to VS2013 on central and aurora)

[Jan de Mooij]

On Thu, May 19, 2016 at 2:59 AM, Emanuel Hoogeveen <
emanuel.hoogev...@gmail.com> wrote:

> They do get the baseline compiler, which can still be significantly faster
> than the interpreter, but Ion requires SSE2. Since the runtime detection
> does just turn Ion off altogether, I don't know if we would gain much by
> removing it (the ability to disable Ion isn't going away).
>

We will have to make a similar decision for WebAssembly. Odin (our
Ion-based asm.js compiler) requires SSE2, but there we can at least use the
much slower 'normal JS' path. For WebAssembly, we have the following
options IIUC:

(1) Don't support wasm on those ancient CPUs. This may work for a while,
but at some point we may include wasm modules in Firefox, normal websites
will start to use it, etc.

(2) Add x87 floating-point support to the wasm baseline JIT - very
complicated and likely not worth it.

(3) Call into C++ for all floating point and SIMD operations. This will be
horribly slow.

(4) Add a wasm interpreter. Again, likely not worth the effort if it's just
for this.

Jan



> IIRC our fuzzers already compile with SSE2 enabled to avoid hitting
> floating point differences during differential testing (testing the
> interpreter against baseline, against Ion). Enabling SSE2 for all builds
> would remove those differences, which might be beneficial in its own right
> (since content JS running in Ion would no longer behave differently than in
> baseline or the interpreter).
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Requiring SSE2 on all 32-bit x86 OSs (was: Re: Reverting to VS2013 on central and aurora)

[Jan de Mooij]

On Thu, May 19, 2016 at 2:59 AM, Emanuel Hoogeveen
 wrote:
>
> They do get the baseline compiler, which can still be significantly faster 
> than the interpreter, but Ion requires SSE2. Since the runtime detection does 
> just turn Ion off altogether, I don't know if we would gain much by removing 
> it (the ability to disable Ion isn't going away).
>

We will have to make a similar decision for WebAssembly. Odin (our
Ion-based asm.js compiler) requires SSE2, but there we can at least
use the much slower 'normal JS' path. For WebAssembly, we have the
following options IIUC:

(1) Don't support wasm on those ancient CPUs. This may work for a
while, but at some point we may include wasm modules in Firefox and
add-ons, normal websites will start to use it, etc.
(2) Add x87 floating-point support to the wasm baseline JIT - very
complicated and likely not worth it.
(3) Call into C++ for all floating point and SIMD operations. This
will be horribly slow.
(4) Add a wasm interpreter. Again, likely not worth the effort if it's
just for this.

Jan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The Object performance are 5-100 times slower than Chrome. Array is a bit slow, map is faster, uint32array are 5 times faster.

[Jan de Mooij]

On Mon, Mar 7, 2016 at 10:42 PM, 罗勇刚(Yonggang Luo) 
wrote:

> My conclution: we really need improve the performance of Object,
> cause that's the most frequently used Thing.
>

I agree plain objects are among "the most frequently used objects", but
here you're using them as arrays and that's not how plain objects are
typically used. Performance of setting indexed properties is mostly
unrelated to setting named properties.

That said, it's a valid performance issue so I filed bug 1254436 [0].
Thanks for reporting this. Next time you run into a JS (performance) issue,
please file a bug in the 'Core: JavaScript Engine' component :)

Thanks,
Jan

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1254436


> ```code
>
> performanceButton.onclick = function () {
>   let startTime = Date.now()
>   ChromeSamples.setStatus(`Start performance testing at time
> ${startTime}`);
>   function testArray(count) {
> let startTime = Date.now()
> let a = []
> for (let i = 0; i < count; ++i) {
>   a[i] = i + 1
> }
> return Date.now() - startTime
>   }
>   function testObject(count) {
> let startTime = Date.now()
> let a = {}
> for (let i = 0; i < count; ++i) {
>   a[i] = i + 1
> }
> return Date.now() - startTime
>   }
>   function testObjectSingle(count) {
> let startTime = Date.now()
> let a = {}
> for (let i = 0; i < count; ++i) {
>   a[0] = i + 1
> }
> return Date.now() - startTime
>   }
>   function testMap(count) {
> let startTime = Date.now()
> let a = new Map()
> for (let i = 0; i < count; ++i) {
>   a.set(i, i + 1)
> }
> return Date.now() - startTime
>   }
>   function testUint32Array(count) {
> let startTime = Date.now()
> let a = new Uint32Array(count)
> for (let i = 0; i < count; ++i) {
>   a[i] = i + 1
> }
> return Date.now() - startTime
>   }
>   setTimeout(function () {
> let count = 1000
> let testResult = {
>   array: testArray(count),
>   object: testObject(count),
>   objectSingle: testObjectSingle(count),
>   map: testMap(count),
>   uint32Array: testUint32Array(count),
> }
> ChromeSamples.setStatus(`Start performance ending at time
> ${JSON.stringify(testResult)}`);
>   })
> }
> ```
> Firefox:
> Start performance ending at time Start performance ending at time
> {"array":340,"object":4762,"objectSingle":2699,"map":5151,"uint32Array":29}
> Chrome:
> Start performance ending at time
> {"array":215,"object":614,"objectSingle":49,"map":6232,"uint32Array":100}
>
> --
>  此致
> 礼
> 罗勇刚
> Yours
> sincerely,
> Yonggang Luo
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: TIFU by using Math.random()

[Jan de Mooij]

On Wed, Nov 25, 2015 at 7:59 PM, Chris Peterson 
wrote:

> On 11/25/15 5:51 AM, Xidorn Quan wrote:
>
>> After reading this article as well as some introduction from the
>> wikipedia, it seems to me that "xorshift+" is probably the best
>> algorithm to adopt, because it is simple, fast, and passes all tests
>> in TestU01 [1], which indicates it should also have a good quality.
>>
>
> We have an implementation of the xorshift128+ PRNG in
> mfbt/XorShift128PlusRNG.h from bug 1206356 that could be used.
>

I landed patches to use this RNG for Math.random() [0]. xorshift128+ does
very well in statistical tests and is very fast (faster than our previous
one actually). Interestingly, V8 and JSC are using the same algorithm now
(since a few days).

Jan

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=322529
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Arrow functions now have a lexical `arguments` binding

[Jan De Mooij]

Hi all,

Yesterday I landed a patch to change how `arguments` works inside arrow
functions [0]. `arguments` is now lexically bound (inherited from the outer
function), similar to `this`. For example, the following function will now
return 1 instead of 2:

  (function() {
var f = () = arguments[0];
return f(2);
  })(1);

Arrow functions no longer have their own arguments object, but rest
parameters are a good alternative in most cases: (...args) = args[i]

Our codebase (chrome, tests, Gaia) relied on the old behavior in a number
of places [1][2], so I think people should be aware of this subtle change.

Thanks,
Jan

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=889158
[1] https://hg.mozilla.org/mozilla-central/rev/a7b04b9e4f17
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1196202,
https://bugzilla.mozilla.org/show_bug.cgi?id=1197787
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: SpiderMonkey and XPConnect style changing from |T *p| to |T* p|

[Jan De Mooij]

I just pushed this to inbound (rev 0c030f97a04f).

Jan

On Thu, Mar 26, 2015 at 11:52 PM, Jan De Mooij jdemo...@mozilla.com wrote:

 Hi all,

 After some discussion, we want to switch SpiderMonkey and XPConnect style
 for pointers/references from |T *p| to |T* p| (and |T ref| to |T ref|).
 This matches the rest of the project and will make life easier for
 developers working on multiple parts of the tree.

 Although this will break a lot of patches, you can run the script in bug
 1144366 [0] on patch files too and they should apply cleanly after that
 (make sure you have backups):

 restyle.py --files patch1 [patch2..]

 The plan is to land this change next weekend or early next week. We'll
 likely land this on aurora/beta/ESR as well, to avoid painful uplifts.

 Finally, a common argument for the current style is that it might be
 clearer when you declare multiple pointers, like this:

 int *x, *y;   // x and y are int*

 However, I think this is pretty confusing either way, and both our style
 guide [1] and Stroustrup [2] suggest sticking to one pointer per
 declaration. I'll write a separate patch to do this.

 I'm very sorry for the rebase and merge pain, but we think this is worth
 doing.

 Thanks,
 Jan

 [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1144366
 [1]
 https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Declarations
 [2] http://www.stroustrup.com/bs_faq2.html#whitespace

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: SpiderMonkey and XPConnect style changing from |T *p| to |T* p|

[Jan De Mooij]

On Fri, Mar 27, 2015 at 5:12 PM, Bobby Holley bobbyhol...@gmail.com wrote:

 On Thu, Mar 26, 2015 at 10:37 PM, Birunthan Mohanathas 
 birunt...@mohanathas.com wrote:

 I've done all of that and more on a few directories (e.g. xpcom/ in
 bug 1046841). If we reach consensus regarding js/ style, I could take
 care of the conversion over the summer.


 That would be awesome! I'm in favor, and I'm pretty sure that jorendorff
 and jandem would be as well. Jason/Jan, can you confirm?


I don't have strong opinions on coding style, as long as we pick one and
use it consistently. MFBT is a good argument to switch: SpiderMonkey uses
Vector and some others in a ton of places and if eventually all MFBT
classes will have methods that start with an uppercase letter, it will get
a bit awkward. On the other hand, going from 99 columns to 80 will also be
annoying in a bunch of places.

It's up to Jason :)

Jan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

SpiderMonkey and XPConnect style changing from |T *p| to |T* p|

[Jan De Mooij]

Hi all,

After some discussion, we want to switch SpiderMonkey and XPConnect style
for pointers/references from |T *p| to |T* p| (and |T ref| to |T ref|).
This matches the rest of the project and will make life easier for
developers working on multiple parts of the tree.

Although this will break a lot of patches, you can run the script in bug
1144366 [0] on patch files too and they should apply cleanly after that
(make sure you have backups):

restyle.py --files patch1 [patch2..]

The plan is to land this change next weekend or early next week. We'll
likely land this on aurora/beta/ESR as well, to avoid painful uplifts.

Finally, a common argument for the current style is that it might be
clearer when you declare multiple pointers, like this:

int *x, *y;   // x and y are int*

However, I think this is pretty confusing either way, and both our style
guide [1] and Stroustrup [2] suggest sticking to one pointer per
declaration. I'll write a separate patch to do this.

I'm very sorry for the rebase and merge pain, but we think this is worth
doing.

Thanks,
Jan

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1144366
[1]
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Declarations
[2] http://www.stroustrup.com/bs_faq2.html#whitespace
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: __noSuchMethod__ is deprecated in SpiderMonkey

[Jan De Mooij]

We've deprecated [0] __noSuchMethod__ [1] support in SpiderMonkey. It's a
non-standard feature that no other engine supports, and it's been hindering
ongoing performance work as __noSuchMethod__ is not trivial to support in
the JITs.

I've posted patches to convert all in-tree and add-on SDK uses and we'll
add a console warning when __noSuchMethod__ is used [2].

There's no drop-in replacement, but in most cases you can either use ES6
proxies or rewrite the code to add the properties you care about manually.

I don't know when/if we can remove this feature from SpiderMonkey, but
we'll likely wait at least a few months to avoid breaking too many add-ons.
In the meantime, please don't add or review code that uses __noSuchMethod__.

Thanks,
Jan

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=683218
[1]
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/noSuchMethod
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1140428
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform