malloc/zone0/allocated

24 views
Skip to first unread message

passfree

unread,
Jul 7, 2011, 10:47:37 AM7/7/11
to
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.

Nicholas Nethercote

unread,
Jul 7, 2011, 11:43:00 PM7/7/11
to passfree, dev-pl...@lists.mozilla.org

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

unread,
Jul 8, 2011, 4:08:05 AM7/8/11
to
This is awesome work. Thanks. I am experiencing some memory issues so
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

unread,
Jul 8, 2011, 4:27:45 AM7/8/11
to
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?

Nicholas Nethercote

unread,
Jul 8, 2011, 5:09:57 AM7/8/11
to passfree, dev-pl...@lists.mozilla.org
On Fri, Jul 8, 2011 at 6:27 PM, passfree <pass...@googlemail.com> wrote:
> 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

unread,
Jul 8, 2011, 8:47:06 AM7/8/11
to passfree, dev-pl...@lists.mozilla.org
Yes, it should include the workers.

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

unread,
Jul 12, 2011, 1:09:55 PM7/12/11
to Mike Shaver, passfree, dev-pl...@lists.mozilla.org
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:

Kyle Huey

unread,
Jul 12, 2011, 1:13:44 PM7/12/11
to Ehsan Akhgari, passfree, dev-pl...@lists.mozilla.org, Mike Shaver
On Tue, Jul 12, 2011 at 10:09 AM, Ehsan Akhgari <ehsan....@gmail.com>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.
>

There has been talk of per-global-object compartments for some time now.

- Kyle

Andreas Gal

unread,
Jul 12, 2011, 1:18:23 PM7/12/11
to Ehsan Akhgari, passfree, dev-pl...@lists.mozilla.org, Mike Shaver

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

unread,
Jul 12, 2011, 1:34:55 PM7/12/11
to
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.

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

unread,
Jul 12, 2011, 1:39:27 PM7/12/11
to Boris Zbarsky, dev-pl...@lists.mozilla.org

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

unread,
Jul 12, 2011, 9:51:41 PM7/12/11
to Boris Zbarsky, dev-pl...@lists.mozilla.org
On Wed, Jul 13, 2011 at 3:34 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
>
> 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

unread,
Jul 12, 2011, 9:53:04 PM7/12/11
to Andreas Gal, passfree, Ehsan Akhgari, dev-pl...@lists.mozilla.org, Mike Shaver
On Wed, Jul 13, 2011 at 3:18 AM, Andreas Gal <g...@mozilla.com> wrote:
>
> 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

unread,
Jul 12, 2011, 10:32:32 PM7/12/11
to Nicholas Nethercote, passfree, Ehsan Akhgari, dev-pl...@lists.mozilla.org, Mike Shaver

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

unread,
Jul 12, 2011, 11:25:44 PM7/12/11
to Andreas Gal, passfree, Ehsan Akhgari, dev-pl...@lists.mozilla.org, Mike Shaver
On Wed, Jul 13, 2011 at 12:32 PM, Andreas Gal <g...@mozilla.com> wrote:
>
>
> 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

unread,
Jul 13, 2011, 3:55:15 AM7/13/11
to
passfree wrote:
> 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

unread,
Jul 13, 2011, 4:50:48 AM7/13/11
to
Jean-Marc Desperrier wrote:

about:memory runs with the system principal, so it's already included in
the except.

--
Warning: May contain traces of nuts.

Boris Zbarsky

unread,
Jul 13, 2011, 12:09:55 PM7/13/11
to
On 7/8/11 4:27 AM, passfree wrote:
> 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

unread,
Jul 13, 2011, 2:14:50 PM7/13/11
to Nicholas Nethercote, passfree, Andreas Gal, dev-pl...@lists.mozilla.org, Mike Shaver

I filed bug 671352 for this.

Ehsan

Reply all
Reply to author
Forward
0 new messages