[JS-internals] Switching from NULL to nullptr

I'm planning to land a few patches over in bug 784739 I'm planning to land a few patches which will switch over parts of the JS engine from using NULL to C++11 nullptr (thanks to the awesome work of Birunthan Mohanathas). I expect Birunthan to write more patches to switch over the rest of this cod

Re: [JS-internals] Switching from NULL to nullptr

Forgot to mention that a script similar to < https://bug626472.bugzilla.mozilla.org/attachment.cgi?id=647139> can be used to unbitrot your patches after this, if needed. -- Ehsan <http://ehsanakhgari.org/> On Mon, Sep 23, 2013 at 9:40 PM, Ehsan Akhgari wrote: > I'm pl

Re: [JS-internals] New bugzilla component for JIT bugs

On 2013-10-07 11:05 AM, Andrew McCreight wrote: If you do end up doing a mass move, then you should put some distinctive string in a message along with the move, along with an explanation of how to filter it out. That makes clearing out the bugmail pretty easy. You could ask Ehsan for advice

Re: [JS-internals] Reviving a JS specific tree

I don't have a horse in this race, but I have quite a bit of experience managing trees in the past, so I'm going to list a number of downsides to this proposal to hopefully help making a more informed decision. 1. js-inbound *will* be busted, and *will* be closed for bustage same as any other

[JS-internals] Changes to the Promise ES6 spec

Hi everyone, We are on track to ship our Promise implementation in Firefox 29. Blink has already shipped their implementation on the stable channel of Chrome and they are facing difficulties determining whether they should change what they have shipped based on the recent ES6 changes to the Promi

Re: [JS-internals] Changes to the Promise ES6 spec

mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals Ehsan Akhgari <mailto:ehsan.akhg...@gmail.com> February 17, 2014 at 12:56 PM Hi everyone, We are on track to ship our Promise implementation in Firefox 29. Blink has already s

Re: [JS-internals] Mentored bugs and good first SpiderMonkey bugs

On 2014-04-21, 7:27 PM, Benjamin Peterson wrote: I'm rather out of the loop, so I can't mention anything specifically. However, if there are any small harmony features to be implemented, those can be a lot of fun for new contributors. (You can tell your friends "I implemented that" when they star

Re: [JS-internals] Firefox's JS throttling heuristics?

On 2014-12-12 7:00 AM, smaug wrote: On 12/09/2014 12:46 AM, Chris Peterson wrote: On 12/8/14 2:28 PM, Boris Zbarsky wrote: On 12/8/14, 3:18 PM, Chris Peterson wrote: Are Firefox's JS throttling heuristics (e.g. for background tabs) documented somewhere? Is this policy controlled by SpiderMonke

Re: [JS-internals] bad frame pointer values on the stack

On 2015-01-09 10:52 AM, Luke Wagner wrote: On x86, the jits use ebp as a general purpose register (16.6% more gprs!) so corruption is expected if you try to walk the stack using the classic ebp/saved-ebp-linked-list traversal that nsStackWalk.cpp:894 is trying to do. I vaguely recall that, some

Re: [JS-internals] C++ Exception Handling

There is also the issue of writing exception safe code, which is extremely difficult to do, especially when you have piles of code assume there are no exceptions. Just turning exceptions on will cause incorrect behavior (where a scope does the wrong thing when terminated by an exception, such

Re: [JS-internals] C++ Exception Handling

On 2016-01-04 2:55 PM, Mike Shaver wrote: Has there been some innovation in EH since Cargill's spine-chilling exploration of making a simple container strongly exception safe? I recall the consensus being that it was quite difficult to actually be strongly exception safe, but it sounds like that'

Re: [JS-internals] C++ Exception Handling

On 2016-01-04 4:48 PM, Luke Wagner wrote: right now!), writing exception safe code is not just a matter of using RAII and dtors to clean up. Please see for example. Yes; noone is suggesting there's an automatic conversion; it'd be a lot of careful work. Agr

[JS-internals] js/JS namespace

As far as I understand, the js namespace is used internally in SpiderMonkey, and the JS namespace contains the public API symbols. However, I occasionally come across things in the public headers in namespace js that I need to use. Examples include js::GCPolicy, js::RootedBase, js::GetBuiltinClass

Re: [JS-internals] js/JS namespace

On 2016-04-19 11:48 PM, Jeff Walden wrote: > On 04/19/2016 08:37 PM, Ehsan Akhgari wrote: >> As far as I understand, the js namespace is used internally in >> SpiderMonkey, and the JS namespace contains the public API symbols. >> However, I occasionally come across things in

[JS-internals] Generating an ErrorReport from a thrown value

What's the correct way to get detailed information about an exception in SpiderMonkey? Right now I'm using js::ErrorReport and am getting a JSErrorReport* out of it, like this: < https://github.com/mozilla/spidernode/blob/a8d3d29956b6b7378b004e1dcde60f6528c60386/deps/spidershim/src/v8message.cc#L3

Re: [JS-internals] Generating an ErrorReport from a thrown value

On 2016-05-04 12:02 PM, Boris Zbarsky wrote: > On 5/4/16 11:40 AM, Ehsan Akhgari wrote: >> 1. If the JS code throws an ErrorObject (such as |throw new >> Error("foo");|) >> I get the line and column info as expected, but if it throws something >> else >>

Re: [JS-internals] Generating an ErrorReport from a thrown value

Thanks for the responses, I filed bug 1270610 for this! On Thu, May 5, 2016 at 1:39 PM, Jim Blandy wrote: > setPendingException isn't always a throw point. Sometimes we're just > managing exceptions previously created: restoring an exception temporarily > set aside for a `finally` block, say. >

Re: [JS-internals] Clang-format

On 2016-05-12 9:53 AM, Nicolas B. Pierron wrote: > The more we empower people for working only on their domain(s) of > expertise, the less we would have need for such heroes. Having persons > responsible for the integration would help us on that. As someone who has worked on many parts of the bro

Re: [JS-internals] Clang-format

On 2016-05-13 8:01 AM, Anthony Ramine wrote: > On Friday, May 13, 2016 at 2:04:25 AM UTC+2, Ehsan Akhgari wrote: >> The current reality how web browsers are made don't afford us treating >> our codebase in that way any more. To me, discussions around unifying >> the c

Re: [JS-internals] Clang-format

On 2016-05-13 8:44 AM, Nicolas B. Pierron wrote: > On 05/13/2016 12:04 AM, Ehsan Akhgari wrote: >> On 2016-05-12 9:53 AM, Nicolas B. Pierron wrote: >>> The more we empower people for working only on their domain(s) of >>> expertise, the less we would have need for s

Re: [JS-internals] Error reporting changes

On 2016-06-01 1:03 PM, Jan de Mooij wrote: > Hi all, > > Just a heads-up: we want to change how exceptions are reported to the > embedding [0]. > > The current/old behavior: the embedding sets an error reporter callback > (JS_SetErrorReporter), and the engine calls this when it throws an > except

Re: [JS-internals] Heads up: Don't use NSPR threading anymore, use js/src/threading/* instead!

On 2016-08-15 2:15 PM, Nick Fitzgerald wrote: > You may have seen some bug mail for > https://bugzilla.mozilla.org/show_bug.cgi?id=956899 and its dependent bugs. > Well, the migration off of NSPR threading is almost complete! Please don't > introduce any more uses of NSPR threading or jslock.h, and

[JS-internals] Overriding Error constructors

I'd like to emulate the format of the V8's stack property on Error objects in SpiderNode. The approach that I have tried is to override the Error (and its family types) constructors on the global object with my own which reformats the stack to emulate the V8 format. This works well for things suc

Re: [JS-internals] Overriding Error constructors

* V8's format is more human readable > * Error().stack's format is not constrained by any standard, so in > theory > changing it is web compatible... > > > On Tue, Sep 27, 2016 at 1:54 PM, Ehsan Akhgari > mailto:ehsan.akhg...@gmail.com&

Re: [JS-internals] Overriding Error constructors

On 2016-09-28 2:13 PM, Nick Fitzgerald wrote: > ​On Wed, Sep 28, 2016 at 9:25 AM, Ehsan Akhgari <mailto:ehsan.akhg...@gmail.com>> wrote: > > On 2016-09-27 5:44 PM, Bobby Holley wrote: > > I heard some years ago that there exist websites which sniffs UAs and >

Re: [JS-internals] JS engine multithreading

On 2017-01-27 11:24 AM, Brian Hackett wrote: > On Fri, Jan 27, 2017 at 8:55 AM, Benjamin Smedberg > wrote: >> Is there something that explains a little more what gains this will buy us >> or how it will be used at the DOM level? > > The best link I think is Bill's Quantum DOM blog post: > > http

Re: [JS-internals] JS engine multithreading

On 2017-01-27 2:12 PM, Brian Hackett wrote: > On Fri, Jan 27, 2017 at 10:06 AM, Julian Seward wrote: >> On 27/01/17 16:36, Brian Hackett wrote: >>> Any thoughts or comments? >> >> It would be really good if testing for data races with TSan could be >> an integral, routine part of this development

Re: [JS-internals] JS engine multithreading

On Fri, Jan 27, 2017 at 3:56 PM, Ehsan Akhgari wrote: > On 2017-01-27 11:24 AM, Brian Hackett wrote: > > On Fri, Jan 27, 2017 at 8:55 AM, Benjamin Smedberg > > wrote: > >> Is there something that explains a little more what gains this will buy > us > >> or

Re: [JS-internals] How JS team members decide what to work on

On 2017-04-12 5:33 AM, Jan de Mooij wrote: > On Tue, Apr 11, 2017 at 11:25 PM, Steve Fink wrote: > >> The juxtaposition of telemetry and the IC logger makes me wonder -- is it, >> or could it be, lightweight enough to report on via telemetry? It would be >> pretty cool to be able to drive work of

Re: [JS-internals] Proposal: always use braces for if/for/while statements

On Tue, Sep 4, 2018 at 12:49 PM Bobby Holley wrote: > +1 > > The one downside of doing this now is that we'll eventually do another bulk > reformat of all of mozilla-central once we settle on a clang-format > version+config whose output we're happy with. So if that were to happen > very soon (unl