SpiderMonkey Newsletter #8

(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

SpiderMonkey Newsletter #7

(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

Re: Dogfooding Warp

/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 >

Dogfooding Warp

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

SpiderMonkey Newsletter #6

(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

SpiderMonkey Newsletter #5

(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

SpiderMonkey Newsletter #4

(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

SpiderMonkey Newsletter #3

(This newsletter is also available on our blog .) JavaScript  New contributors - Rob Rico tidied up some code in the parser  New features - Yulia

SpiderMonkey Newsletter #2

ine, 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 landin

Re: PSA: You can use UTF8String from WebIDL

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

Re: SpiderMonkey Newsletter #1

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 mea

Re: Upcoming changes to hg.mozilla.org access

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

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

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

Re: JS testing functions and compartments in mochitest-plain

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 >

Re: JS testing functions and compartments in mochitest-plain

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 >

Re: clang version on tryserver?

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 );

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

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

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

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

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

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

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

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

PSA: Compartments will soon contain multiple global objects

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

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

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

Re: Gecko-visible Latin1 analog of JS_NewUCString()

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

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

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

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

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

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

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

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

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 m

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

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

Re: Introducing mozilla::Result for better error handling

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

Re: Introducing mozilla::Result for better error handling

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

Introducing mozilla::Result for better error handling

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

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

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

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

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

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

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

Re: TIFU by using Math.random()

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

Arrow functions now have a lexical `arguments` binding

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 = () =

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

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

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

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

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

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

PSA: __noSuchMethod__ is deprecated in SpiderMonkey

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