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 expando
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
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.
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
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 changes
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
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
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
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 bzbar...@mit.edu 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
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 andreas@gmail.com wrote:
JS is a big advantage for rapid implementation of features and
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
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 only
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
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
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,
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 do
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 hackers,
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
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
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
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 #
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 change
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).
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,
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
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:
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
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
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
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
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
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 roadmap
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
locking
On Mon, Apr 22, 2013 at 1:32 PM, Nicholas Nethercote
n.netherc...@gmail.com 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
On Mon, Apr 22, 2013 at 9:48 PM, Justin Lebar justin.le...@gmail.comwrote:
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
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 of these
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 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 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%) --
On Tue, Apr 23, 2013 at 5:36 AM, Terrence Cole tc...@mozilla.com 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
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
On Mon, Apr 22, 2013 at 6:35 PM, Justin Dolske dol...@mozilla.com 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
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
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 ehsan.akhg...@gmail.com wrote:
This was a
44 matches
Mail list logo
