malloc/zone0/allocated
passfree
consumed by the main thread, and is it possible to get memory listing
per loaded XUL page? I am trying to pinpoint high memory usage.
Nicholas Nethercote
about:memory has been thoroughly overhauled in FF6, and FF7 (now on
Aurora) extends it again to give measurements per JS "compartment",
which roughly means that JS measurements are broken down by the script
origins. Try it, it might help you a lot. See the first part of
http://blog.mozilla.com/nnethercote/2011/07/06/memshrink-progress-week-3/
for some more details.
Nick
passfree
hopefully soon I will be able to write some tests to catch them in
future releases. I haven't pinpoint where the problems are but this
will help alot.
On Jul 8, 4:43 am, Nicholas Nethercote <n.netherc...@gmail.com> wrote:
> On Fri, Jul 8, 2011 at 12:47 AM, passfree <passf...@googlemail.com> wrote:
> > Is this property from the about:memory page related to how much was
> > consumed by the main thread, and is it possible to get memory listing
> > per loaded XUL page? I am trying to pinpoint high memory usage.
>
> about:memory has been thoroughly overhauled in FF6, and FF7 (now on
> Aurora) extends it again to give measurements per JS "compartment",
> which roughly means that JS measurements are broken down by the script
> origins. Try it, it might help you a lot. See the first part ofhttp://blog.mozilla.com/nnethercote/2011/07/06/memshrink-progress-wee...
passfree
This is what I get from the about:memory
├──598,394,138 B (87.08%) -- js
│ ├──482,025,064 B (70.15%) -- compartment([System Principal])
│ │ ├──461,672,804 B (67.19%) -- string-chars
│ │ ├───12,529,664 B (01.82%) -- gc-heap
│ │ │ ├───6,085,104 B (00.89%) -- objects
│ │ │ ├───3,543,360 B (00.52%) -- shapes
│ │ │ ├───1,360,800 B (00.20%) -- strings
│ │ │ ├───1,284,184 B (00.19%) -- arena-unused
│ │ │ ├─────182,688 B (00.03%) -- arena-padding
│ │ │ ├──────73,416 B (00.01%) -- arena-headers
│ │ │ └─────────112 B (00.00%) -- xml
I presume compartment([System Principal]) is related to chrome. Does
that include workers instantiated from xul pages?
Nicholas Nethercote
> I must say Firefox7 is lighting fast. Awesome work.
>
> This is what I get from the about:memory
>
> ├──598,394,138 B (87.08%) -- js
> │ ├──482,025,064 B (70.15%) -- compartment([System Principal])
> │ │ ├──461,672,804 B (67.19%) -- string-chars
> │ │ ├───12,529,664 B (01.82%) -- gc-heap
> │ │ │ ├───6,085,104 B (00.89%) -- objects
> │ │ │ ├───3,543,360 B (00.52%) -- shapes
> │ │ │ ├───1,360,800 B (00.20%) -- strings
> │ │ │ ├───1,284,184 B (00.19%) -- arena-unused
> │ │ │ ├─────182,688 B (00.03%) -- arena-padding
> │ │ │ ├──────73,416 B (00.01%) -- arena-headers
> │ │ │ └─────────112 B (00.00%) -- xml
>
> I presume compartment([System Principal]) is related to chrome. Does
> that include workers instantiated from xul pages?
I don't know, sorry. But that's a huge string-chars number. You must
have a lot of long strings somewhere.
Nick
Mike Shaver
Can test by running one that creates a million objects and checking the
output, I bet. :-)
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
Ehsan Akhgari
as, per XUL file/js module/etc)? I've noticed that with the
per-compartment info on about:memory, chrome is the only part of the
browser which seems like a black-box as far as the JS memory usage goes.
Ehsan
On 11-07-08 8:47 AM, Mike Shaver wrote:
> Yes, it should include the workers.
>
> Can test by running one that creates a million objects and checking the
> output, I bet. :-)
> On Jul 8, 2011 4:31 AM, "passfree"<pass...@googlemail.com> wrote:
Kyle Huey
> Would it be possible to create multiple compartments for chrome (such as,
> per XUL file/js module/etc)? I've noticed that with the per-compartment
> info on about:memory, chrome is the only part of the browser which seems
> like a black-box as far as the JS memory usage goes.
>
There has been talk of per-global-object compartments for some time now.
- Kyle
Andreas Gal
Yes, we can definitely split chrome into compartments. The main reason we didn't do that initially was the fact that content code was already using wrappers before, so we didn't expect too much fall-out from introducing content compartments. Chrome code on the other hand is used to being able to access everything without wrappers in between, so we do expect some (add-on, frontend code) compatibility issues. Obvious benefits would be precise resource account for extensions, amongst others.
Andreas
On Jul 12, 2011, at 10:09 AM, Ehsan Akhgari wrote:
> Would it be possible to create multiple compartments for chrome (such as, per XUL file/js module/etc)? I've noticed that with the per-compartment info on about:memory, chrome is the only part of the browser which seems like a black-box as far as the JS memory usage goes.
>
> Ehsan
>
> On 11-07-08 8:47 AM, Mike Shaver wrote:
>> Yes, it should include the workers.
>>
>> Can test by running one that creates a million objects and checking the
>> output, I bet. :-)
>> On Jul 8, 2011 4:31 AM, "passfree"<pass...@googlemail.com> wrote:
Boris Zbarsky
> Would it be possible to create multiple compartments for chrome (such
> as, per XUL file/js module/etc)? I've noticed that with the
> per-compartment info on about:memory, chrome is the only part of the
> browser which seems like a black-box as far as the JS memory usage goes.
Note that we have multiple compartments in chrome right this second,
that are all being reported together. In particular, each sandbox gets
its own compartment, but about:memory treats them as all identical.
I sort of wonder whether we could flag sandbox compartments with some
information about what created them (a callstack?) and expose all that
in about:memory... or something.
-Boris
Andreas Gal
On Jul 12, 2011, at 10:34 AM, Boris Zbarsky wrote:
> On 7/12/11 1:09 PM, Ehsan Akhgari wrote:
>> Would it be possible to create multiple compartments for chrome (such
>> as, per XUL file/js module/etc)? I've noticed that with the
>> per-compartment info on about:memory, chrome is the only part of the
>> browser which seems like a black-box as far as the JS memory usage goes.
>
> Note that we have multiple compartments in chrome right this second, that are all being reported together. In particular, each sandbox gets its own compartment, but about:memory treats them as all identical.
Right. For sandboxes we always had a wrapper in between, so this wasn't the kind of change in behavior we were worried about.
Andreas
>
> I sort of wonder whether we could flag sandbox compartments with some information about what created them (a callstack?) and expose all that in about:memory... or something.
>
> -Boris
Nicholas Nethercote
>
> Note that we have multiple compartments in chrome right this second, that
> are all being reported together. In particular, each sandbox gets its own
> compartment, but about:memory treats them as all identical.
>
> I sort of wonder whether we could flag sandbox compartments with some
> information about what created them (a callstack?) and expose all that in
> about:memory... or something.
I've opened bug 671159 to report them separately. Each one won't have
any distinguishing information, we can think about adding that later
if things are still unclear.
N
Nicholas Nethercote
>
> Yes, we can definitely split chrome into compartments. The main reason we didn't do that initially was the fact that content code was already using wrappers before, so we didn't expect too much fall-out from introducing content compartments. Chrome code on the other hand is used to being able to access everything without wrappers in between, so we do expect some (add-on, frontend code) compatibility issues. Obvious benefits would be precise resource account for extensions, amongst others.
What are the other benefits? With my MemShrink hat on I'd love to
have a better breakdown of Chrome memory usage, but if that's the only
benefit and it makes life harder or slower in various other ways, it
might not be a good idea.
Nick
Andreas Gal
I don't expect this to be substantially slower. Extensions shouldn't be talking to frontend code all that much, and even if they do, we have to make wrappers fast anyway for one-global-per-compartment.
Andreas
>
> Nick
Nicholas Nethercote
>
>
> I don't expect this to be substantially slower. Extensions shouldn't be talking to frontend code all that much, and even if they do, we have to make wrappers fast anyway for one-global-per-compartment.
In that case, anything that can identify per-add-on memory usage would
be a godsend to both users and developers.
N
Jean-Marc Desperrier
> This is what I get from theabout:memory
>
> ├──598,394,138 B (87.08%) -- js
> │ ├──482,025,064 B (70.15%) -- compartment([System Principal])
> │ │ ├──461,672,804 B (67.19%) -- string-chars
> │ │ ├───12,529,664 B (01.82%) -- gc-heap
> │ │ │ ├───6,085,104 B (00.89%) -- objects
> │ │ │ ├───3,543,360 B (00.52%) -- shapes
> │ │ │ ├───1,360,800 B (00.20%) -- strings
> │ │ │ ├───1,284,184 B (00.19%) -- arena-unused
> │ │ │ ├─────182,688 B (00.03%) -- arena-padding
> │ │ │ ├──────73,416 B (00.01%) -- arena-headers
> │ │ │ └─────────112 B (00.00%) -- xml
It would be nice to be able to minimise each branch of this, and extend
when needed. But I suppose something like that is probably done at the
moment.
I couldn't identify the "about:memory" compartment in my list ? Is it
the one shown as "about:void" ?
Neil
about:memory runs with the system principal, so it's already included in
the except.
--
Warning: May contain traces of nuts.
Boris Zbarsky
> This is what I get from the about:memory
>
> ├──598,394,138 B (87.08%) -- js
> │ ├──482,025,064 B (70.15%) -- compartment([System Principal])
> │ │ ├──461,672,804 B (67.19%) -- string-chars
That's insane. 460MB of string data stored in chrome? What's going on
there?
-Boris
Ehsan Akhgari
I filed bug 671352 for this.
Ehsan