> The ratio of things landed on inbound which turn out to busted is really
> worrying
> * 116 of the 916 changesets (12.66%) were backed out
If 13% is "really worrying", what do you think our goal should be?
On Tue, Apr 23, 2013 at 12:39 AM, Ehsan Akhgari wrote:
> This was a fantastic read, it
This was a fantastic read, it almost made me shed happy tears! Thanks a
lot kats for doing this.
The ratio of things landed on inbound which turn out to busted is really
worrying, and it might be an indicator that (some?) developers have a
poor judgement on how safe their patches are. How ha
On Mon, Apr 22, 2013 at 6:35 PM, Justin Dolske wrote:
>
> That said, I think it's critically important that we're working to make JS a
> acceptable -- nay, _excellent_ -- language/runtime for application
> development for the long run. We can't tell a credible story about why
> people should write
On 4/21/13 4:51 PM, Justin Lebar wrote:
What I'd like to come out of this thread is a consensus one way or another as
to whether we continue along our current path of writing many features that are
enabled on B2G in JS, or whether we change course.
First -- B2G should clearly do whatever it ne
On Apr 22, 2013, at 17:39 , Jeff Walden wrote:
> On 04/22/2013 04:34 PM, Norbert Lindenberg wrote:
>> 3) Related to that, some properties are documented as part of the wrong
>> object. For example, the String.prototype documentation shows a length
>> property. String.prototype doesn't have this
On Tue, Apr 23, 2013 at 5:36 AM, Terrence Cole wrote:
> Our exact rooting work is at a spot right now where we could easily use
> more hands to accelerate the process. The main problem is that the work
> is easy and tedious: a hard sell for pretty much any hacker at mozilla.
>
It sounds worthwhi
On 04/22/2013 04:34 PM, Norbert Lindenberg wrote:
> 3) Related to that, some properties are documented as part of the wrong
> object. For example, the String.prototype documentation shows a length
> property. String.prototype doesn't have this property; String instances do.
String.prototype is a
It seems there are several distinct problems:
1) The page
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/String
right now doesn't show the methods that String instances inherit from
String.prototype. This is most likely a symptom of this bug:
https://bugzilla.mozilla
On 23/04/13 24:18 , Nicolas B. Pierron wrote:
On 04/22/2013 07:53 AM, Justin Lebar wrote:
This is the wifi worker. I think "script-sources" is code. Note that
fragmentation (unused-arenas) is way too high, but even despite this
the worker uses too much memory.
2.38 MB (05.13%) -- worker(reso
On 04/22/2013 07:53 AM, Justin Lebar wrote:
This is the wifi worker. I think "script-sources" is code. Note that
fragmentation (unused-arenas) is way too high, but even despite this
the worker uses too much memory.
2.38 MB (05.13%) -- worker(resource://gre/modules/wifi_worker.js, 0x45584800)
On 4/22/13 5:22 PM, Jeff Muizelaar wrote:
I don't know if there's anything surprising here. Calling into JS from C++ goes
through xpconnect which is a long standing slowness.
_That_ we can try to fix by converting to JS-implemented WebIDL. Right
now that performs about the same, but we know
On 2013-04-22, at 3:44 PM, Terrence Cole wrote:
> On 04/22/2013 12:12 PM, Jeff Muizelaar wrote:
>> On 2013-04-22, at 2:15 PM, Bill McCloskey wrote:
>>
>>> I can't agree with you more, Justin. I think Boris is right that we should
>>> make these decisions on a case-by-case basis. But in the case
On Mon, Apr 22, 2013 at 9:48 PM, Justin Lebar wrote:
> > This is all great stuff, but as mentioned elsewhere, B2G branched at
> > version 18 and so they need improvements that that can land quickly on
> > the relevant branches.
>
I understand that (but should certainly have made it more clear).
On Mon, Apr 22, 2013 at 1:32 PM, Nicholas Nethercote
wrote:
>
> - Looking at the merged.json data: the system principal compartment
> merging is happening on the main process, but doesn't appear to be
> happening on all the other processes: Homescreen, Usage,
> (Preallocated app).
I filed https
> This is all great stuff, but as mentioned elsewhere, B2G branched at
> version 18 and so they need improvements that that can land quickly on
> the relevant branches.
Well, to be clear, it would be great if we could land some
improvements for v1.1 (which is based off version 18), but we're
locki
On Mon, Apr 22, 2013 at 1:25 PM, Till Schneidereit
wrote:
> There are a few things we're working on in SpiderMonkey that should improve
> this situation quite a bit:
>
> ...generational GC...
>
> making bytecode generation lazy...
> ...re-lazyfication of JSScripts...
> ...lazy cloning of JSScripts
> There are a few things we're working on in SpiderMonkey that should improve
> this situation quite a bit:
Thanks, but I again need to emphasize that these are large, long-term
plans. Terrence tells me that GGC is planned for "sometime this
year". Lazy bytecode generation has been on the roadma
Some comments on this whole thread:
- I'm very sympathetic to Justin's concerns. 120 MiB is not much
memory. While it's (somewhat) ok to kill apps that are using too much
memory, that doesn't work with the main B2G process, and I've been
CC'd on enough "the B2G main process is using too much mem
There are a few things we're working on in SpiderMonkey that should improve
this situation quite a bit:
Terrence already mentioned generational GC, which certainly is the largest
piece by far. Getting rid of all or almost all memory lost to fragmentation
makes the tradeoff a considerably different
I agree, it is also super tedious to set up and update. You always
have to remember to go to /prototype and sometimes you need to clear
the caching of the pages that include it. I think some these pages
sometimes have extra information that is not included in the main
page, but I doubt many people
TL;DR:
* Inbound is closed 25% of the time
* Turning off coalescing could increase resource usage by up to 60% (but
probably less than this).
* We spend 24% of our machine resources on changes that are later backed
out, or changes that are doing the backout
* The vast majority of changesets that
On 04/22/2013 12:12 PM, Jeff Muizelaar wrote:
> On 2013-04-22, at 2:15 PM, Bill McCloskey wrote:
>
>> I can't agree with you more, Justin. I think Boris is right that we should
>> make these decisions on a case-by-case basis. But in the case of these
>> workers, it seems clear that converting the
Boris - sorry, these are event listeners.
Bobby - that would rock. I'm removing the event listeners manually but this
requires some hardcoded dependencies to jQuery that I'd love to get rid of.
___
dev-platform mailing list
dev-platform@lists.mozilla.or
On 2013-04-22, at 2:15 PM, Bill McCloskey wrote:
> I can't agree with you more, Justin. I think Boris is right that we should
> make these decisions on a case-by-case basis. But in the case of these
> workers, it seems clear that converting them to C++ is the way to go,
> assuming we have the
On 04/22/2013 11:07 AM, Justin Lebar wrote:
>> I can't really agree or disagree without knowing why they use "too much"
>> memory.
> At the risk of sounding like a broken record, it's all in the memory
> reports. You probably understand this data better than I do. Extract
> and load in about:memo
Currently, the JavaScript reference content for the global classes
(String, Array, etc), are divided up such that the class methods and
properties and the prototype methods and properties are documented
separately, with links between them. For example, see:
https://developer.mozilla.org/en-US/
Mike Hommey wrote:
On Sun, Apr 21, 2013 at 07:51:18PM -0400, Justin Lebar wrote:
I think we should consider using much less JS in the parts of Gecko that are
used in B2G. I'd like us to consider writing new modules in C++ where
possible, and I'd like us to consider rewriting existing modules
I can't agree with you more, Justin. I think Boris is right that we
should make these decisions on a case-by-case basis. But in the case of
these workers, it seems clear that converting them to C++ is the way to
go, assuming we have the resources to do so.
-Bill
On 04/22/2013 11:07 AM, Justin
> I can't really agree or disagree without knowing why they use "too much"
> memory.
At the risk of sounding like a broken record, it's all in the memory
reports. You probably understand this data better than I do. Extract
and load in about:memory (button is at the bottom).
http://people.mozill
On 04/21/2013 04:51 PM, Justin Lebar wrote:
> I think we should consider using much less JS in the parts of Gecko that are
> used in B2G. I'd like us to consider writing new modules in C++ where
> possible, and I'd like us to consider rewriting existing modules in C++.
>
> I'm only proposing a ch
On 13-04-22 12:50 PM, Benjamin Smedberg wrote:
On 4/22/2013 12:41 PM, Kannan Vijayan wrote:
There are a whole bunch of arguments-object related crashes showing
up that I think are related to my push over the weekend which enabled
arguments-object support in Ion. I'm working on resolving thes
Meeting Details:
* Agenda: https://wiki.mozilla.org/WebAPI/2013-04-23
* WebAPI Vidyo room
* Amoeba conf. room, San Francisco office (7A)
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office
* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone # 1
On 4/22/2013 12:41 PM, Kannan Vijayan wrote:
There are a whole bunch of arguments-object related crashes showing up
that I think are related to my push over the weekend which enabled
arguments-object support in Ion. I'm working on resolving these
quickly. :decoder seems to have generated a
There are a whole bunch of arguments-object related crashes showing up
that I think are related to my push over the weekend which enabled
arguments-object support in Ion. I'm working on resolving these
quickly. :decoder seems to have generated a nice fuzz bug in debug mode
that's simple and
To hopefully close the loop on this, 860438 – Remove custom cx-stack munging
scattered around Gecko was backed out to resolve the crash in 863646 – Start up
crash in nsContentUtils::GetCurrentJSContext in profile manager (-p ,
-profilemanager, always ask at startup).
That leaves the crash regre
Our (ostensibly) weekly DOM bindings meetings continue on Monday April 22th
at 12:30 PM PDT.
Meeting details:
* Monday, April 22, 2013, 12:30 PM PDT (3:30 PM EDT/9:30 PM CEST)
* Conference room 7-N, San Francisco office, 7th floor.
* Dial-in Info:
- Vidyo room: SFO-7N
- In office or soft phone:
> So to the extent that b2g is in a "not enough hands" situation, implementing
> in JS
> makes sense.
I don't feel like b2g is in this position. We don't have a lot of
Gecko hackers with 2+ years of experience, but we do have a lot of
hackers. Whether or not we have a lot of C++ versus JS hacke
> How about making the JS engine use jemalloc instead of its own
> allocator? Does anything actually rely on the arenas being independent
> at the paging level?
My understanding, which may be wrong, is that the JS engine needs to
be able to quickly map an object's address to a compartment. They d
On Mon, Apr 22, 2013 at 10:53:40AM -0400, Justin Lebar wrote:
> > How about pre-compiling JS in JITed form?
>
> While significant, it seems that memory used for script source isn't
> the biggest offender.
>
> Full details are in the about:memory reports,
>
> http://people.mozilla.org/~jlebar/dow
> How about pre-compiling JS in JITed form?
While significant, it seems that memory used for script source isn't
the biggest offender.
Full details are in the about:memory reports,
http://people.mozilla.org/~jlebar/downloads/merged.json.xz
http://people.mozilla.org/~jlebar/downloads/unmerged.jso
On 4/21/13 7:51 PM, Justin Lebar wrote:
Since most of these features implemented in JS seem to be DOM features, I'm
particularly interested in the opinions of the DOM folks.
Opinions differ. ;)
I think for DOM features that are not invoked on most pages,
implementing them in JS seems like a
On Sun, Apr 21, 2013 at 07:51:18PM -0400, Justin Lebar wrote:
> I think we should consider using much less JS in the parts of Gecko that are
> used in B2G. I'd like us to consider writing new modules in C++ where
> possible, and I'd like us to consider rewriting existing modules in C++.
>
> I'm o
> I think I would like to hear from the JS team on reducing memory use of JS and
> disabling any compilation for infrequently running code before we give
> up on it.
The issue isn't compilation of code; that doesn't stick out in the
memory reports. The issue seems to be mostly the overhead of the
The things on Justin's list do not appear to be infrequently running code.
Wifi, RIL, Apps, mozbrowser, etc are going to be running all the time.
- Kyle
On Mon, Apr 22, 2013 at 7:11 AM, Andreas Gal wrote:
> JS is a big advantage for rapid implementation of features and it's
> easier to avoid e
I've filed bug 864313 for improving the situation here. Should be pretty
straightforward to do.
On Mon, Apr 22, 2013 at 9:20 AM, Boris Zbarsky wrote:
> On 4/22/13 4:37 AM, Matthew Gertner wrote:
>
>> However, the sandbox lives on if it contains DOM event handlers that have
>> not been removed.
JS is a big advantage for rapid implementation of features and it's
easier to avoid exploitable mistakes. Also, in many cases JS code
(bytecode, not data) should be slimmer than C++. Using JS for
infrequently executing code should be a memory win. I think I would
like to hear from the JS team on re
Of course attachments don't work great on newsgroups. I've uploaded
the about:memory dumps I tried to attach to people.m.o:
http://people.mozilla.org/~jlebar/downloads/merged.json.xz
http://people.mozilla.org/~jlebar/downloads/unmerged.json.xz
On Sun, Apr 21, 2013 at 7:51 PM, Justin Lebar wrote
I think we should consider using much less JS in the parts of Gecko that are
used in B2G. I'd like us to consider writing new modules in C++ where
possible, and I'd like us to consider rewriting existing modules in C++.
I'm only proposing a change for modules which are enabled for B2G. For modul
This work has been completed, and trees reopened as of 12:06 PT (19:06 UTC).
Thanks for everyone's help & cooperation.
--Hal
On 2013-04-18 17:22 , John O'Duinn wrote:
> hi;
>
> We will have a treeclosing maintenance window Sunday, April 21 from
> 10:00-14:00PT (17:00-21:00UTC). This is for chang
On 4/22/13 4:37 AM, Matthew Gertner wrote:
However, the sandbox lives on if it contains DOM event handlers that have not
been removed.
Event handlers, or event listeners?
For event listeners, this happens because they're not holding
cross-compartment wrappers, presumably... and that's not li
The Web Apps Working Group at W3C has published a Proposed
Recommendation, Web Storage (the stage before W3C's final stage,
Recommendation):
http://www.w3.org/TR/2013/PR-webstorage-20130409/
There's a call for review to W3C member companies (of which Mozilla
is one) open until Tuesday, May 7.
I
Someone who knows that code better should comment, but
I assume it should also replace the Metro javascript pan/zoom
stuff at some point, perhaps backed by native gesture detection
when the page doesn't have touch handlers, and using b2g's
gesture detection at other times? Maybe that's orthogonal
I don't think we fire touch events on OSX, so probably not an issue. I'm
confident Android's behavior is more compliant that Win8 desktop. Metro is
somewhere in between. Wes makes a good point in the next follow up about
moving simulated click events into shared code to help standardize. For now
On Wednesday, April 17, 2013 3:57:58 PM UTC+2, Bobby Holley wrote:
> When you want the sandbox to die, you can do
> |Components.utils.nukeSandbox(sandbox)|, and it'll go away. Simple as that.
> :-)
I've been using this, and it indeed nukes the sandbox even if there are
backreferences from expand
54 matches
Mail list logo