On Monday 2014-03-17 13:31 -0400, Richard Eyre wrote:
> Thanks for adding me Anne, you did get my email correct :-).
>
> Personally, I'm not interested in developing TTML. I still agree to all the
> points from our previous discussion from the page you linked, Anne.
>
> I'm not really sure whethe
On 3/21/14, 10:23 PM, K. Gadd wrote:
> A hypothetical scenario (please ignore any minor detail errors, I'm
> using this to illustrate the scenario): Let's say I have a main
> document and it spawns 3 popup windows as documents. The popup windows
> have references to the parent document and use them
In many cases the point at which an object becomes uninteresting is
the point at which it is unreachable, and no deterministically
identifiable point before that. It is true that in many cases you
don't need anything resembling weak references, and can simply
manually mark objects as dead. There ar
On 2014-03-21 1:07 PM, Gavin Sharp wrote:
On Fri, Mar 21, 2014 at 7:40 AM, Irving Reid wrote:
extensions.blocklist.pingCountVersion (146 times out of ~1.5 million Nightly
telemetry sessions) and extensions.shownSelectionUI (8 times in 1.5m)
The prefs in question aren't likely targets for mal
On Thursday 2014-03-20 13:38 -0400, Irving Reid wrote:
> In a way we're dancing around competing footguns here - do we
> protect against bad code trying to break our preferences by setting
> a value to the wrong type, or do we protect against a broken
> preference messing up our code because we can
On 3/21/14 10:14 PM, Jim Blandy wrote:
It's true that when I read, "We are discovering a lot of leaks in JS
implemented DOM objects", I wasn't sure what he was referring to...
He means APIs exposed to the web whose implementation is a JS component.
So typically these are objects whose useful l
On 03/21/2014 05:03 PM, Boris Zbarsky wrote:
On 3/21/14 6:34 PM, Jim Blandy wrote:
I don't believe there are any DOM nodes involved in the situation that
Kyle described at the start of this thread...
It's true that when I read, "We are discovering a lot of leaks in JS
implemented DOM objects",
On 3/21/14 6:34 PM, Jim Blandy wrote:
What if these DOM nodes
I don't believe there are any DOM nodes involved in the situation that
Kyle described at the start of this thread...
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
h
On 3/21/14, 5:42 PM, Jim Blandy wrote:
> On 03/21/2014 03:34 PM, Jim Blandy wrote:
>> What if these DOM nodes could use a special class of observers /
>> listeners that automatically set themselves aside when the node is
>> deleted from the document, and re-instate themselves if the node is
>> re-i
On 03/21/2014 03:34 PM, Jim Blandy wrote:
What if these DOM nodes could use a special class of observers /
listeners that automatically set themselves aside when the node is
deleted from the document, and re-instate themselves if the node is
re-inserted in the document? Similarly for when the win
On 03/19/2014 04:39 PM, Kyle Huey wrote:
Short of not implementing things in JS, what ideas do people have for
fixing these issues? We have some ideas of how to add helpers to
scope these things to the lifetime of the window (perhaps by adding an
API that returns a promise that is resolved at in
On Fri, Mar 21, 2014 at 2:00 PM, Nicholas Nethercote
wrote:
>>
>> What is the per-compartment overhead?
>
> It's hard to pin an exact number on it. It depends on exactly the
> mixture of GC things allocated by the compartment. But in my current
> session, the smallest two system compartments take
- Original Message -
> From: "Nicholas Nethercote"
> To: "Benjamin Smedberg"
> Cc: "dev-platform"
> Sent: Friday, March 21, 2014 2:00:01 PM
> Subject: Re: Too many system compartments at start-up
>
> Marco identified a number of modules that could be lazily loaded, and
> filed several b
On Fri, Mar 21, 2014 at 6:31 AM, Benjamin Smedberg
wrote:
>
> What is the per-compartment overhead?
It's hard to pin an exact number on it. It depends on exactly the
mixture of GC things allocated by the compartment. But in my current
session, the smallest two system compartments take up only 4,7
On Fri, Mar 21, 2014 at 2:45 PM, Andrew McCreight wrote:
> Looking at a recent AWSY run, in StartSettled, I see three non-window
> zones.
>
> One is about 22mb and contains all the stuff you'd expect, browser.xul,
> various .jsm files etc.
>
> The second is is 2.8mb, almost entirely strings. Ther
We're now running b2g reftests on EC2 on every trunk branch side-by-side
with the Fedora minis:
https://tbpl.mozilla.org/?jobname=b2g_emulator.*reftest
They're running around 30-40% slower. We are looking at enabling them on
faster EC2 instances so we can disable the minis.
regards,
Armen
On 14-
We're now running b2g reftests on EC2 on every trunk branch side-by-side
with the Fedora minis:
https://tbpl.mozilla.org/?jobname=b2g_emulator.*reftest
They're running around 30-40% slower. We are looking at enabling them on
faster EC2 instances so we can disable the minis.
regards,
Armen
On 14-
Looking at a recent AWSY run, in StartSettled, I see three non-window zones.
One is about 22mb and contains all the stuff you'd expect, browser.xul, various
.jsm files etc.
The second is is 2.8mb, almost entirely strings. There's one string that is
about 10,000 long, but the rest are non-notab
On Fri, Mar 21, 2014 at 2:23 PM, Boris Zbarsky wrote:
> On 3/21/14 1:09 PM, Bobby Holley wrote:
>
>> For JSMs and stuff, they should all go into the system zone.
>>
>
> I realize that, emphasis on "should". Have we verified that this is
> happening?
Maybe bill did, at some point? This is prett
On 03/21/2014 12:06 PM, Bill McCloskey wrote:
The problem with doing measurements is that the per-compartment overhead is
very dependent on what's going on in the compartment. I tried to enable the B2G
compartment merging stuff in desktop Firefox to get a sense of how much of a
change there wo
On 3/21/14 1:09 PM, Bobby Holley wrote:
For JSMs and stuff, they should all go into the system zone.
I realize that, emphasis on "should". Have we verified that this is
happening?
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On Fri, Mar 21, 2014 at 1:37 PM, Boris Zbarsky wrote:
> On 3/21/14 11:02 AM, Bobby Holley wrote:
>
>> I'm also curious to hear about the overhead of compartments now that we
>> have zones.
>>
>
> An important question: which of these system compartments actually share a
> zone with each other? I
On Fri, Mar 21, 2014 at 7:40 AM, Irving Reid wrote:
> extensions.blocklist.pingCountVersion (146 times out of ~1.5 million Nightly
> telemetry sessions) and extensions.shownSelectionUI (8 times in 1.5m)
> The prefs in question aren't likely targets for malware, though they could
> be collateral d
On 3/21/14, 9:06 AM, Bill McCloskey wrote:
- Original Message -
From: "Bobby Holley"
To: "Benjamin Smedberg"
Cc: "dev-platform" , "Nicholas Nethercote"
Sent: Friday, March 21, 2014 8:02:58 AM
Subject: Re: Too many system compartments at start-up
I'm also curious to hear about the ov
On 3/21/14, 9:36 AM, Bill McCloskey wrote:
- Original Message -
From: "Gregory Szorc"
To: "Nicholas Nethercote"
Cc: "dev-platform"
Sent: Friday, March 21, 2014 9:27:34 AM
Subject: Re: Too many system compartments at start-up
Also, the bug I was referring to is bug 807205. It was mark
On 3/21/14 11:02 AM, Bobby Holley wrote:
I'm also curious to hear about the overhead of compartments now that we
have zones.
An important question: which of these system compartments actually share
a zone with each other? I know the goal is "all of them", but are we
actually getting there?
- Original Message -
> From: "Gregory Szorc"
> To: "Nicholas Nethercote"
> Cc: "dev-platform"
> Sent: Friday, March 21, 2014 9:27:34 AM
> Subject: Re: Too many system compartments at start-up
>
> Also, the bug I was referring to is bug 807205. It was marked WONTFIX
> because gc now happ
On 3/21/14, 1:37 AM, Nicholas Nethercote wrote:
On Fri, Mar 21, 2014 at 12:16 AM, Gregory Szorc wrote:
Could someone please provide an update on reducing compartment overhead?
Are we at a point where things like services/healthreport/HealthReport.jsm should be considered a
"necessary evil" ra
- Original Message -
> From: "Bobby Holley"
> To: "Benjamin Smedberg"
> Cc: "dev-platform" , "Nicholas Nethercote"
>
> Sent: Friday, March 21, 2014 8:02:58 AM
> Subject: Re: Too many system compartments at start-up
>
> I'm also curious to hear about the overhead of compartments now tha
On Thu, 20 Mar 2014 17:11:01 +0100, Anne van Kesteren
wrote:
On Thu, Mar 20, 2014 at 3:17 PM, Boris Zbarsky wrote:
http://dev.w3.org/csswg/cssom/#the-css.escape%28%29-method which allows
web
pages to create a valid CSS identifier that will parse to a given
string. A
typical use case is
On Fri, Mar 21, 2014 at 10:31 AM, Benjamin Smedberg
wrote:
> On 3/21/2014 2:46 AM, Nicholas Nethercote wrote:
>
>> Hi,
>>
>> At start-up, with a new profile, Firefox creates more than 230 system
>> compartments. This is about 90 more than a year ago, and it's part of
>> the reason why Firefox uses
On 21/03/2014 15:37, Benjamin Smedberg wrote:
On 3/21/2014 10:34 AM, Marco Bonardo wrote:
Or directly make Cu.import act like defineLazyModuleGetter... Would
that be possible?
I don't think that's a good idea. It's not an uncommon pattern to
try/catch around a module import in case it's not p
On 2014-03-20 5:38 PM, Gavin Sharp wrote:
On Thu, Mar 20, 2014 at 10:38 AM, Irving Reid wrote:
For unknown reasons, internal bookkeeping prefs used by AddonManager and
XPIProvider are set to values of the wrong type on some Firefox profiles,
and are now stuck that way. I can write wrapper code
On 3/21/2014 10:34 AM, Marco Bonardo wrote:
Or directly make Cu.import act like defineLazyModuleGetter... Would
that be possible?
I don't think that's a good idea. It's not an uncommon pattern to
try/catch around a module import in case it's not present in a
particular configuration or the
I started filing some low-hanging-fruit dependencies, though, looks like
one of the main culprit is modules that are Cu.import-ed instead of
defineLazyModuleGetter-ed.
I wonder if we could somehow instrument Cu.import so that if a module is
not used before N seconds (or M ticks?) from when it
On 2014-03-20 5:03 PM, Neil wrote:
Irving Reid wrote:
For unknown reasons, internal bookkeeping prefs used by AddonManager
and XPIProvider are set to values of the wrong type on some Firefox
profiles, and are now stuck that way. I can write wrapper code on
these calls to catch the error and cle
Nicholas Nethercote schrieb:
Hi,
At start-up, with a new profile, Firefox creates more than 230 system
compartments. This is about 90 more than a year ago, and it's part of
the reason why Firefox uses almost twice as much physical memory at
start-up than it did two years ago.
Hrm, reading your
On 3/21/2014 2:46 AM, Nicholas Nethercote wrote:
Hi,
At start-up, with a new profile, Firefox creates more than 230 system
compartments. This is about 90 more than a year ago, and it's part of
the reason why Firefox uses almost twice as much physical memory at
start-up than it did two years ago.
If my memory serves, B2G has its own implementation of Cu.import that
doesn't create components. Would it be possible to expose this
implementation to Firefox so that we could use it for some modules that
are designed to be always be imported together?
I would definitely use this for OS.File.
Sim
On Fri, Mar 21, 2014 at 12:16 AM, Gregory Szorc wrote:
> Could someone please provide an update on reducing compartment overhead?
>
> Are we at a point where things like services/healthreport/HealthReport.jsm
> should be considered a "necessary evil" rather than a "gross hack?"
>
> What other sol
On 3/20/14 12:11 PM, Anne van Kesteren wrote:
Seems fine, specification should probably clarify surrogate handling.
I would expect a paired surrogate in JavaScript to end up as a single
escape.
Non-ASCII stuff is OK in CSS idents, so it doesn't need escaping at all:
it's just left as-is.
-Bo
Could someone please provide an update on reducing compartment overhead?
Are we at a point where things like services/healthreport/HealthReport.jsm
should be considered a "necessary evil" rather than a "gross hack?"
What other solutions besides concatenating files and lazy loading are there?
Ne
42 matches
Mail list logo
