Re: Async Iteration is available on non-release-only, for testing purpose
I agree that disabling for chrome is the right thing here over prefs. I want Nightly and DevEdition to have stage 3+ TC39 proposals unflagged and ready to play with -- asking folks to turn on prefs to do that is not the way to go here from my perspective. Benjamin's concern is legit, though, so let's disable it in chrome. On Mon, Mar 27, 2017 at 9:12 AM, Till Schneidereit < t...@tillschneidereit.net> wrote: > I think disabling in chrome code is a good idea. We have done these kinds > of non-release-only features in the JS engine in the past, and it hasn't > always gone well precisely for the reasons that have you concerned. OTOH, > adding a pref is annoyingly complicated for JS engine features (we should > probably work on that!) and makes the feature much harder to test for web > developers. Perhaps for now disabling for chrome is really the right > trade-off? > > On Mon, Mar 27, 2017 at 7:56 AM, Benjamin Smedberg > wrote: > > > I am concerned about the accidental consequences of turning this on for > > nightly/aurora. What if we start writing browser code that relies on > these > > features which unexpectedly starts failing in beta? > > > > I presume the value of enabling this in nightly/aurora is that we can get > > web developers to experiment and report bugs? Is that something we can > do > > asking them to explicitly turn this on via pref? Or are you worried about > > this feature accidentally breaking existing web content and you want to > get > > bug reports from normal users? > > > > Could we mitigate risk by disabling this feature in chrome code by > default > > until you're confident in its readiness to ship? > > > > --BDS > > > > > > On Mon, Mar 27, 2017 at 10:33 AM, Tooru Fujisawa > > wrote: > > > > > I just landed the initial implementation of Async Iteration proposal > > > (async generator and for-await-of syntax), as non-release-only feature. > > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1331092 > > > > > > The implementation is only for the testing purpose (for finding spec > bug > > > etc), and the semantic change in the spec is highly expected. They're > > not > > > yet ready for production usage, either in browser code or in testcases. > > > Please wait for a while :) > > > > > > -- > > > > > > arai > > > > > > ___ > > > 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 > -- shu ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Async Iteration is available on non-release-only, for testing purpose
Cross-posting to firefox-dev. TL;DR: arai has done truly excellent feature work implementing the ECMAScript Async Iteration proposal. It is gated to Nightly/DevEd only for content code. We will also be turning off the feature in chrome code to prevent accidental dependence. Both these restrictions will be lifted when the proposal fully matures to be in the next standard. *PLEASE DO NOT USE ASYNC GENERATORS IN CHROME CODE.* On Mon, Mar 27, 2017 at 9:31 AM, Shu-yu Guo wrote: > I agree that disabling for chrome is the right thing here over prefs. I > want Nightly and DevEdition to have stage 3+ TC39 proposals unflagged and > ready to play with -- asking folks to turn on prefs to do that is not the > way to go here from my perspective. > > Benjamin's concern is legit, though, so let's disable it in chrome. > > On Mon, Mar 27, 2017 at 9:12 AM, Till Schneidereit < > t...@tillschneidereit.net> wrote: > >> I think disabling in chrome code is a good idea. We have done these kinds >> of non-release-only features in the JS engine in the past, and it hasn't >> always gone well precisely for the reasons that have you concerned. OTOH, >> adding a pref is annoyingly complicated for JS engine features (we should >> probably work on that!) and makes the feature much harder to test for web >> developers. Perhaps for now disabling for chrome is really the right >> trade-off? >> >> On Mon, Mar 27, 2017 at 7:56 AM, Benjamin Smedberg > > >> wrote: >> >> > I am concerned about the accidental consequences of turning this on for >> > nightly/aurora. What if we start writing browser code that relies on >> these >> > features which unexpectedly starts failing in beta? >> > >> > I presume the value of enabling this in nightly/aurora is that we can >> get >> > web developers to experiment and report bugs? Is that something we can >> do >> > asking them to explicitly turn this on via pref? Or are you worried >> about >> > this feature accidentally breaking existing web content and you want to >> get >> > bug reports from normal users? >> > >> > Could we mitigate risk by disabling this feature in chrome code by >> default >> > until you're confident in its readiness to ship? >> > >> > --BDS >> > >> > >> > On Mon, Mar 27, 2017 at 10:33 AM, Tooru Fujisawa >> > wrote: >> > >> > > I just landed the initial implementation of Async Iteration proposal >> > > (async generator and for-await-of syntax), as non-release-only >> feature. >> > > >> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1331092 >> > > >> > > The implementation is only for the testing purpose (for finding spec >> bug >> > > etc), and the semantic change in the spec is highly expected. They're >> > not >> > > yet ready for production usage, either in browser code or in >> testcases. >> > > Please wait for a while :) >> > > >> > > -- >> > > >> > > arai >> > > >> > > ___ >> > > 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 >> > > > > -- >shu > -- shu ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: Use strict in function with non-simple parameters
No evidence either way. Given we've had non-compat parameter defaults for a
while, your worry is legit. We'll deal with web compat issues with JS as it
comes up -- unfortunately the reality is that until we ship something, we
have very little idea if it's breaking.
On Fri, Oct 7, 2016 at 8:14 AM, Ehsan Akhgari
wrote:
> On 2016-10-07 8:01 AM, Tom Schuster wrote:
> > To simplify parsing ES 2016 disallows "use strict" in functions with
> > non-simple parameters, like defaults or rest.
> >
> > For example `function f(a = 1) { "use strict"; }` is going to start
> > throwing.
> >
> > Chrome, JSC and Edge already made this change.
>
> Do we have any evidence to suggest that making this change doesn't break
> webpages in Gecko, if they're using browser sniffing to parse code that
> they don't parse in other engines?
>
> Thanks,
> Ehsan
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
--
shu
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Changes in chrome JS code due to ES6 global lexical scope
Good catch and thanks for the correction! The take-home from the example is that: due to the global lexical scope, a TDZ error could arise later due to newly introduced bindings. On Thu, Sep 17, 2015 at 7:34 PM, Boris Zbarsky wrote: > On 9/17/15 8:26 PM, Shu-yu Guo wrote: > >> The first call to f() does not throw. >> > > It actually does, because the bareword lookup for "x" fails. You get > "ReferenceError: x is not defined". > > If you replaced "x" with "window.x" or "self.x" or "this.x" or something I > think you'd get the behavior you describe. > > -Boris > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- shu ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Changes in chrome JS code due to ES6 global lexical scope
(Isn't that bananas, by the way?)
On Thu, Sep 17, 2015 at 5:26 PM, Shu-yu Guo wrote:
> On Thu, Sep 17, 2015 at 5:18 PM, Neil wrote:
>
>> Shu-yu Guo wrote:
>>
>> 4. The global lexical scope is extensible. This means dynamic scope
>>> (lol!):
>>>
>>>
>>> function f() { dump(x); }
>>> f(); // prints undefined
>>>
>>>
>>>
>>> let x = 42;
>>> f(); // prints 42
>>>
>>>
>>> Would you mind clarifying what this is supposed to demonstrate? It looks
>> to me that this is demonstrating TDZ semantics, and under ES6 the first
>> call to f() will throw.
>>
>
> The first call to f() does not throw. These are two separate
> tags, and during the execution of the first <script> tag, there is no
> global lexical binding named 'x', so no TDZ semantics are triggered.
> Instead, undefined is printed because there is no binding named 'x' and
> presumably the 'x' property on the global object is undefined.
>
> When we execute the second <script> tag, we now have made a global lexical
> binding named 'x'. When we call f() again, it will print the value of that
> binding.
>
> To contrast, the following two scripts would throw due to TDZ:
>
> <script>
> function f() { dump(x); }
> f(); // doesn't throw, prints undefined
>
>
>
> f(); // throws due to TDZ
> let x;
>
>
>
> The second call to f() throws because during the second script's
> execution, there is an uninitialized global lexical binding 'x'.
>
>
>> --
>> Warning: May contain traces of nuts.
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
>
> --
>shu
>
--
shu
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Changes in chrome JS code due to ES6 global lexical scope
On Thu, Sep 17, 2015 at 5:18 PM, Neil wrote:
> Shu-yu Guo wrote:
>
> 4. The global lexical scope is extensible. This means dynamic scope (lol!):
>>
>>
>> function f() { dump(x); }
>> f(); // prints undefined
>>
>>
>>
>> let x = 42;
>> f(); // prints 42
>>
>>
>> Would you mind clarifying what this is supposed to demonstrate? It looks
> to me that this is demonstrating TDZ semantics, and under ES6 the first
> call to f() will throw.
>
The first call to f() does not throw. These are two separate
tags, and during the execution of the first <script> tag, there is no
global lexical binding named 'x', so no TDZ semantics are triggered.
Instead, undefined is printed because there is no binding named 'x' and
presumably the 'x' property on the global object is undefined.
When we execute the second <script> tag, we now have made a global lexical
binding named 'x'. When we call f() again, it will print the value of that
binding.
To contrast, the following two scripts would throw due to TDZ:
<script>
function f() { dump(x); }
f(); // doesn't throw, prints undefined
f(); // throws due to TDZ
let x;
The second call to f() throws because during the second script's
execution, there is an uninitialized global lexical binding 'x'.
> --
> Warning: May contain traces of nuts.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
--
shu
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Changes in chrome JS code due to ES6 global lexical scope
Hello all,
We are in the process of implementing the global lexical scope per ES6.
This changes the semantics of global level 'let' and 'const' bindings from
our non-standard semantics to standard semantics.
Currently, global 'let' and 'const' bindings introduce properties onto the
global object. Global 'let' behaves identically to 'var', and global
'const' is like 'var', with the exception that the property it introduces
is read-only. Since they behave essentially like 'var', they can be
redeclared and there is no TDZ (i.e., you can use them before their
declarator is reached, resulting in an undefined).
In ES6, this changes.
1. Global 'let' and 'const' are no longer properties on the global object.
They go into a separate global lexical scope.
2. Global 'let' and 'const' may not be redeclared at the global level with
'let', 'const', or 'var'.
3. Global 'let' and 'const' are subject to temporal dead zone (TDZ)
semantics. If they are referenced before their declarator is executed, a
ReferenceError is thrown. For example,
dump(x); // will throw instead of print undefined.
let x = 42;
4. The global lexical scope is extensible. This means dynamic scope (lol!):
function f() { dump(x); }
f(); // prints undefined
let x = 42;
f(); // prints 42
As you can imagine, these changes break all our chrome code. Almost all the
errors are due to 1) and 2).
Due to 1), there are many places where code expects 'let' and 'const'
bindings are expected to be properties. Cu.import is a common offender:
Foo.jsm:
const SOME_CONSTANT = 42;
foo.js:
// SOME_CONSTANT isn't a property on the global scope returned by Cu.import
const { SOME_CONSTANT } = Cu.import("Foo.jsm", {})
Due to 2), there are thousands of places where we redeclare Ci, Cc, Cu,
etc. Many tests redeclare 'let' and 'const' bindings. Test harnesses also
like to inject code with 'let'.
I am in the process of slowly fixing the world.
Because until now, our global 'let' semantics have been identical to
those of 'var', I have already landed a patch that mass replaces global
'let' with 'var' as part of bug 1202902.
Because there is no direct syntactic replacement for 'const', I am combing
through the code on a case by case basis.
For Firefox devs, I ask 2 things:
1) For bindings expected to be properties on the global scope, please do
that explicitly with |this.foo = ...| or 'var' and stop using 'let' and
'const'.
2) Understand the semantics of Cu.import. From reading the code, this seems
commonly misunderstood. The API is |Cu.import(path, targetObj)|. In
pseudocode, what Cu.import does is:
... executes script pointed to path ...
for (symbol of jsmGlobalScope.EXPORTED_SYMBOLS) {
targetObj[symbol] = jsmGlobalScope[symbol];
}
return jsmGlobalScope;
That is, Cu.import's return value is the *entire global scope* of the JSM.
It isn't targetObj. It doesn't respect EXPORTED_SYMBOLS. You can get
anything you want out of the global scope of the JSM.
The relevant bugs are bug 1202902 and bug 589199.
Please reach out on IRC if you have questions.
--
shu
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
PSA: Gecko Profiler Addon and Cleopatra temporarily broken
I landed bug 1154115 today, which changes the format of the JSON spit out by the Gecko profiler. If the patches stick, the Gecko Profiler Addon and Cleopatra will be broken until they are updated. I have submitted pull requests to the two repos. In the meantime, you may elect to use my version of the xpi here: https://people.mozilla.org/~sguo/geckoprofiler.xpi And my version of Cleopatra here: https://people.mozilla.org/~sguo/cleopatra/ Note that B2G will also be broken, but I lack the expertise to fix that. -- shu ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What are your pain points when running unittests?
To build off this idea, I'd like a "run-until-failure" mode (with an upper limit, of course) on try itself. I don't want to spend N+ hours spinning my CPU locally to repro an intermittent. I also don't want to wait until a build is done to press the retrigger button 40 times. My blue-sky wish would be to push a run-until-failure with RR try job, and download the failing replays the next day to debug locally. On Thu, Mar 12, 2015 at 4:34 PM, Seth Fowler wrote: > > > On Mar 12, 2015, at 4:17 PM, Gijs Kruitbosch > wrote: > > It'd be better if we could more easily get more information about > failures as they happened on infra (replay debugging stuff a la what roc > has worked on, or better logs, or somehow making it possible to > remote-debug the infra machines as/when they fail). > > > > ~ Gijs > > Yes! > > I guess (but don’t know for sure) that recording RR data for every test > that gets run might be too expensive. But it’d be nice if we were able to > request that RR data be recording for *particular* tests in the test > manifest. Probably we should make it possible to record it unconditionally, > and to record it only if the test failed. I can see using this in two ways: > > - When I’m investigating a failure, I can push a commit that records RR > data for the test I’m concerned about. > > - We can annotate rare intermittent failures to record RR data whenever > they fail. This obviously means that the tests must be run under RR all the > time, but at least we won’t have to waste storage space on RR data for the > common, passing case. This would be a huge help for some hard-to-reproduce > intermittent failures. > > I’m sure there are a lot of gotchas here, but in an ideal world these > features would be a huge help. > > - Seth > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- shu ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: ES6 lexical temporal dead zone has landed on central
I'm with Jeff on this one. I'm very much against special casing add-on code --
which will invariably develop into another compatibility to break when we
finally do decide to break it.
- Original Message -
From: "Jeff Walden"
To: dev-platform@lists.mozilla.org
Sent: Friday, September 19, 2014 5:51:38 PM
Subject: Re: ES6 lexical temporal dead zone has landed on central
On 09/18/2014 04:18 PM, Kent James wrote:
> Substituting var for let does not result in code that behaves identically to
> previous code, so I can't see why that would be proposed.
The proposal would be to perform the substitution only for let at "body level"
of a function. (And for global let -- which requires its own semantic changes,
see bug 589199, that are in progress but not complete yet.) So this:
let s = "valid";
{ let s = "invalid";}
dump(s);
would be converted to this:
var s = "valid";
{ let s = "invalid";}
dump(s);
with no semantic change.
This substitution is absolutely not a good idea in the long run. In the short
run, for a release or two...maybe. But that's a vry hesitant maybe. I'm
leery of introducing these deviations into the language, such that people write
code expecting the standard semantics and are surprised to find the code
doesn't work as expected in other contexts. How should addons that inject code
into pages behave, for that code? Is this something that an addon author could
easily predict? I could well imagine it working either way. I'd really rather
not go down this path if we can help it.
Jeff
___
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: ES6 lexical temporal dead zone has landed on central
Well, SM's 'let' extension never really let you redeclare let bindings. What
happened was that it was too much work to parse function body-level lets as
actual lets, and so they were parsed as vars, thus allowing "redeclarations".
Keep in mind that vars aren't *really* redeclared. When actual semantics is
closer to erasure semantics: just pretend the second var isn't there. That is,
consider
var x = 42;
var f = function () { print(x); }
var x = 43;
var g = function () { print(x); }
f and g above are closing over the *same* binding of x.
I would bet that Rust lets you actually redeclare (viz. shadow with a new
binding in the same scope) , such that if you had the equivalent code in Rust
above, f and g would close over *different* bindings.
So having lets behave like vars in that respect is probably going to lead to
the same crappiness that we have with vars now. Why they didn't allow shadowing
with a new binding? I don't know, it would be nice -- but perhaps was too big a
break, and that it would behave strangely, or at least surprisingly, with
hoisting semantics.
- Original Message -
From: "Chris Peterson"
To: dev-platform@lists.mozilla.org
Sent: Wednesday, September 17, 2014 4:37:17 PM
Subject: Re: ES6 lexical temporal dead zone has landed on central
On 9/15/14 4:43 PM, Shu-yu Guo wrote:
> If you work with JS that contains `let` bindings, you may start encountering
> the following two errors:
>
>1. TypeError: redeclaration of variable foo
>
> To fix, rename the variable or remove the extra `let` if you are
> assigning to an already-bound variable.
>
> These are static errors. You may pass your JS through the syntax checker
> in the SpiderMonkey shell (-c) to detect them.
Much of the `let` fallout being reported is from variable
redeclarations. For compatibility, perhaps TC39 should reconsider
whether `let` redeclarations are worthy of being static errors.
JS allows you to redeclare vars. Rust allows you to redeclare variables
with `let` (even changing the type!). SpiderMonkey's non-standard JS1.8
allowed you to redeclare variables with `let` (until Shu made it ES6
compatible). Maybe variable redeclarations are not such a big problem
for JS developers.
chris
___
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
ES6 lexical temporal dead zone has landed on central
Hello all, Today I landed bug 1001090 (assuming it doesn't bounce), implementing ES6 lexical temporal dead zone for function-level `let` declarations, on mozilla-central. As a refresher on the email I sent on Aug. 13, this is a backwards-incompatible change. Everything inside mozilla-central needed to make the tree green on TBPL has been fixed. However, this is expected to break addons, comm-central, and possibly B2G code that use `let` (though I was told last time that Gaia does not use `let`). If you work with JS that contains `let` bindings, you may start encountering the following two errors: 1. TypeError: redeclaration of variable foo To fix, rename the variable or remove the extra `let` if you are assigning to an already-bound variable. These are static errors. You may pass your JS through the syntax checker in the SpiderMonkey shell (-c) to detect them. 2. ReferenceError: can't access let declaration `foo' before initialization These are hoisted uses and wacky cases like accessing a `let` binding declared in one switch case in a different case. To fix, don't do those things please. These are dynamic errors. You have to execute your JS to detect them. -- shu ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Non-backward compatible changes to JS 'let' semantics
About not changing the behavior for chrome JS, the prospect of having chrome JS
becoming more divergent from standard JS is unwelcome to me. Having additional,
orthogonal features is one thing, but a fundamental feature with the same
syntax that behaves differently depending on the context is very unsavory.
- Original Message -
From: "Ehsan Akhgari"
To: "Shu-yu Guo" , dev-platform@lists.mozilla.org,
dev-g...@lists.mozilla.org
Cc: "Jorge Villalobos"
Sent: Wednesday, August 13, 2014 2:45:17 PM
Subject: Re: Non-backward compatible changes to JS 'let' semantics
AFAICT gaia doesn't use let in its core code (since let is not available
in non-chrome js yet) but it does use it in its build scripts etc.
However, let is pretty heavily used in add-ons. CCing Jorge who can
probably help with what to do with that. But have we considered not
changing the behavior for chrome JS?
Cheers,
Ehsan
On 2014-08-13, 5:29 PM, Shu-yu Guo wrote:
> Hello all,
>
> We are in the process of making JS 'let' semantics ES6-compliant in
> SpiderMonkey. I hope to land bug 1001090 sometime this month or early next
> month (I've been told there's a B2G uplift on Sept 1st), which is one of many
> for ES6 'let'-compliance. It changes 'let' semantics in two non-backward
> compatible ways:
>
>1. 'let' bindings may no longer redeclare existing bindings in function
> scope. (In ES6, this is also true for global code, but global 'let'
> changes are distinct from bug 1001090 and will be addressed by bug
> 589199.)
>
> Currently, 'let' bindings at the function body-level are semantically
> equivalent to 'var' bindings. This means that the following JS are
> legal:
>
> function f(x) { let x = x || ""; }
> function g() { let x = 42; let x = 43; }
>
> When bug 1001090 lands, these will be syntax errors.
>
>2. 'let' bindings may not be accessed in any fashion before initialization.
> Initialization means execution of the |let x| or |let x = rhs|
> forms. Before initialization, the 'let' bindings are in a "temporal dead
> zone" (TDZ). The TDZ is enforced dynamically, throwing a ReferenceError.
>
> When bug 1001090 lands, the following JS throw:
>
> function f() { x = 42; let x; }
> function g() { function inner() { x = 42; } inner(); let x; }
> function h() { switch (c) { case 0: let x; break; default: x = 42;
> break; } }
>
> These changes wreak havoc on our existing chrome JS, largely due to item 1
> above. It will be a rough landing, so I am raising awareness of these breaking
> changes now. The changes will likely initially land under a Nightly-only
> #ifdef.
>
> I can fix (or can find someone to fix) code that is in mozilla-central. But
> code that is outside of that tree will be problematic. Namely, Gaia and
> addons.
> Can someone own updating Gaia JS to be ES6-compliant? It is unclear to me what
> should be done about addons.
>
> The takeaway for developers is to refrain from using the patterns I've listed
> above starting now in any new code, before bug 1001090 lands. The patterns in
> item 2 above are bad form and should never have been used, but those from item
> 1 have seen a fair bit of use.
>
> P.S. I am not subscribed to dev-gaia. For those on that list but not on
> dev-platform, please reply to me at my email address.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Non-backward compatible changes to JS 'let' semantics
Hello all,
We are in the process of making JS 'let' semantics ES6-compliant in
SpiderMonkey. I hope to land bug 1001090 sometime this month or early next
month (I've been told there's a B2G uplift on Sept 1st), which is one of many
for ES6 'let'-compliance. It changes 'let' semantics in two non-backward
compatible ways:
1. 'let' bindings may no longer redeclare existing bindings in function
scope. (In ES6, this is also true for global code, but global 'let'
changes are distinct from bug 1001090 and will be addressed by bug
589199.)
Currently, 'let' bindings at the function body-level are semantically
equivalent to 'var' bindings. This means that the following JS are legal:
function f(x) { let x = x || ""; }
function g() { let x = 42; let x = 43; }
When bug 1001090 lands, these will be syntax errors.
2. 'let' bindings may not be accessed in any fashion before initialization.
Initialization means execution of the |let x| or |let x = rhs|
forms. Before initialization, the 'let' bindings are in a "temporal dead
zone" (TDZ). The TDZ is enforced dynamically, throwing a ReferenceError.
When bug 1001090 lands, the following JS throw:
function f() { x = 42; let x; }
function g() { function inner() { x = 42; } inner(); let x; }
function h() { switch (c) { case 0: let x; break; default: x = 42;
break; } }
These changes wreak havoc on our existing chrome JS, largely due to item 1
above. It will be a rough landing, so I am raising awareness of these breaking
changes now. The changes will likely initially land under a Nightly-only
#ifdef.
I can fix (or can find someone to fix) code that is in mozilla-central. But
code that is outside of that tree will be problematic. Namely, Gaia and addons.
Can someone own updating Gaia JS to be ES6-compliant? It is unclear to me what
should be done about addons.
The takeaway for developers is to refrain from using the patterns I've listed
above starting now in any new code, before bug 1001090 lands. The patterns in
item 2 above are bad form and should never have been used, but those from item
1 have seen a fair bit of use.
P.S. I am not subscribed to dev-gaia. For those on that list but not on
dev-platform, please reply to me at my email address.
--
shu
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Exposing JIT performance faults in profiler/devtools (was: Are you interested in doing dynamic analysis of JS code?)
Hi Katelyn,
I'm going to refer to what you're talking about with cloning and monomorphism
as the "context sensitivity problem". As far as I know, this is still an open
problem (not in the fundamental sense, just that nobody has a good solution for
it yet) in the JS JITs. The argument types (counting 'this' as an argument) is
one part of the context; the other part being the types of its free variables.
For example, the context sensitivity problem is part of the reason repeated
calls to something like Array.prototype.map is slow, and why any user-written
collections libraries with higher order functions will be slow.
I've experimented with manually hinting functions to be cloned at callsite. We
do this currently in SpiderMonkey only for certain PJS functions, like mapPar.
This is a pretty brittle optimization though, since it can be easily defeated
by wrapping, e.g., function myMapPar(arr, fn) { arr.mapPar(fn); }. I'd love to
solve this problem in general. Such a solution would require:
1) A notion of "context" that's efficient in both time and space (e.g. easy to
compute and cheap to store).
2) A notion of "context" that's robust (e.g. not defeated by wrapping).
3) Ability to determine what functions benefit from being cloned per-context.
PGO sounds like a great way to address 3) that I haven't thought of before. I'd
also love to hear ideas about 1) and 2).
Cheers,
- Original Message -
From: "Jason Orendorff"
To: k...@luminance.org, "Robert O'Callahan"
Cc: "Kannan Vijayan" , dev-platform@lists.mozilla.org,
fitz...@mozilla.com
Sent: Friday, June 27, 2014 1:21:02 PM
Subject: Exposing JIT performance faults in profiler/devtools (was: Are you
interested in doing dynamic analysis of JS code?)
On 06/25/2014 05:51 PM, Katelyn Gadd wrote:
> Maybe you could use mutation/method call tracing to do a
> profile-guided-optimization equivalent for JS where you record
> argument types and clone functions per-callsite to ensure everything
> is monomorphic?
Yes, I think this is something that could be done with it.
But! Note that we're separately working on exposing JIT performance
faults in the profiler/devtools---directly reporting the kind of
problems you're thinking about painstakingly inferring. \o/
I don't know how far along it is, and it's maybe too early to guess how
actionable the output will be, but it's a much more certain thing than
this dynamic analysis API. No meta bug, but several people are working
on aspects of it. Maybe Kannan can tell more. (cc-ing him)
-j
___
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
