Re: GGC (generational garbage collection) has landed for B2G
Having previously worked on a couple of GCs I must say this is amazing work! I don't know many other large, complex code bases such as Gecko that were moved successfully from a conservative mark-and-sweep collector to an accurate generational one. Bravo to everyone involved! Gabriele On 16/09/2014 21:45, Steve Fink wrote: > GGC was enabled yesterday (2014-Sep-15) on b2g-inbound with bug 1020751. > It has not yet been merged into mozilla-central, but I expect it will be > soon. GGC is already on desktop Firefox, and in fact just shipped with > Firefox 32. Keep an eye out for regressions on FxOS. Or improvements, > for that matter -- we'd be interested in any real-world workloads that > see significant changes. signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: GGC (generational garbage collection) has landed for B2G
On 09/16/2014 02:34 PM, Asa Dotzler wrote: > On 9/16/14, 12:45 PM, Steve Fink wrote: >> GGC was enabled yesterday (2014-Sep-15) on b2g-inbound with bug 1020751. >> It has not yet been merged into mozilla-central, but I expect it will be >> soon. GGC is already on desktop Firefox, and in fact just shipped with >> Firefox 32. Keep an eye out for regressions on FxOS. Or improvements, >> for that matter -- we'd be interested in any real-world workloads that >> see significant changes. > > What kind of regressions should we be on the lookout for and in what > situations? Performance? Jank? Stability? Also memory usage and OOM handling. We've had several months to clean things up for desktop; we don't expect any huge issues, although we do have different tuning parameters for the smaller devices. It's hard to tell in advance what sort of issues changing the GC behavior is going to cause or we'd have already investigated. Cheers, Terrence > - A > > ___ > 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
Web APIs documentation meeting Friday
The Web APIs documentation meeting is Friday at 10 AM Pacific Time (see http://bit.ly/APIdocsMDN for your time zone). Everyone's welcome to attend; if you're interested in ensuring that all Web APIs are properly documented, we'd love your input. We have an agenda, as well as details on how to join, here: https://etherpad.mozilla.org/WebAPI-docs-2014-09-19. If you have topics you wish to discuss, please feel free to add them to the agenda. We look forward to seeing you there! If you're unable to attend but have been working on documentation related to APIs, please add notes to the agenda about what you've been doing so we can share your progress. -- Eric Shepherd Developer Documentation Lead Mozilla Blog: http://www.bitstampede.com/ Twitter: @sheppy ___ 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
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
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
Re: ES6 lexical temporal dead zone has landed on central
If this change proves to be really disruptive to add-on authors, I wonder if we
could just make "let" behave like "var" for add-ons? The JS tokenizer could
just substitute var for let when parsing code from an add-on compartment. (Bug
1030420 will put add-on code in a separate compartment and it's ready to land
soon.) I think that would mostly mitigate the concerns Jeff raised in the
previous thread about having to test two configurations.
-Bill
- Original Message -
> From: "Shu-yu Guo"
> To: "Chris Peterson"
> Cc: dev-platform@lists.mozilla.org
> Sent: Wednesday, September 17, 2014 5:26:57 PM
> Subject: 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
