On 7/13/18 5:22 PM, gsquel...@mozilla.com wrote:
E.g., could I instrument one class, so that every allocation would be tracked
automatically, and I'd get nice stats at the end?
You mean apart from just having a memory reporter for it?
Including wasted space because of larger allocation
On Wednesday, July 11, 2018 at 4:19:15 AM UTC+10, Kris Maglione wrote:
> [...]
> Essentially what this means, though, is that if we identify an area of
> overhead that's 50KB[3] or larger that can be eliminated, it *has* to be
> eliminated. There just aren't that many large chunks to remove.
On Fri, Jul 13, 2018 at 11:14:24AM -0400, Randell Jesup wrote:
Hash tables are a big issue. There are a lot of 64K/128K/256K
allocations at the moment for hashtables. When we started looking at
this in bug 1436250, we had a 256K, ~4 128K, and a whole bunch of 64K
hashtable allocs (on linux).
>
>
>
> >Also note that dealing with the "importance" of a page is not just a
> >matter of visibility and focus. There are other factors to take into
> >account such as if the page is playing audio or video (like listening to
> >music on YouTube), if it's self-updating and so on.
>
> Absolutely
>
>On 13/07/2018 04:55, Randell Jesup wrote:
>> Correct - we need to have observers/what-have-you for
>> background/foreground state (and we may want an intermediate state or
>> two - foreground-but-not-focused (for example a visible window that
>> isn't the focused window); recently-in-foreground
>On Thu, Jul 12, 2018 at 08:56:28AM -0700, Andrew McCreight wrote:
>>On Thu, Jul 12, 2018 at 3:57 AM, Emilio Cobos Álvarez
>>wrote:
>>
>>> Just curious, is there a bug on file to measure excess capacity on
>>> nsTArrays and hash tables?
[snip]
>I kind of suspect that improving the storage
This touches on a really important point: we're not the only ones
allocating memory.
Just a few that come to mind: GPU drivers, system media codecs, a11y
tools, and especially on Windows we have to deal with "utility"
applications, corporate-mandated gunk, and downright crapware.
When we're
Just another bit of info to raise awareness on a thorny issue we have to
face if we want to significantly raise the number of content processes.
On 64-bit Windows we often consume significantly more commit space than
physical memory. This consumption is currently unaccounted for in
about:memory
On 13/07/2018 04:55, Randell Jesup wrote:
> Correct - we need to have observers/what-have-you for
> background/foreground state (and we may want an intermediate state or
> two - foreground-but-not-focused (for example a visible window that
> isn't the focused window); recently-in-foreground
>On 07/12/2018 11:08 PM, Randell Jesup wrote:
>> We may need to trade first-load time against memory use by lazy-initing
>> more things than now, though we did quite a bit on that already for
>> reducing startup time.
>
>One thing to remember that some of the child processes will be more
On Fri, Jul 13, 2018 at 1:56 AM, Andrew McCreight
wrote:
> >
> > Just curious, is there a bug on file to measure excess capacity on
> > nsTArrays and hash tables?
>
> njn looked at that kind of issue at some point (he changed how arrays grow,
> for instance, to reduce overhead), but it has
On Fri, Jul 13, 2018, at 6:51 AM, Kris Maglione wrote:
> I actually have a patch sitting around with helpers to make it super easy to
> use smart pointers as tagged pointers :) I never wound up putting it up for
> review, since my original use case went away, but it you can think of any
>
On Fri, Jul 13, 2018, at 7:08 AM, smaug wrote:
> One thing to remember that some of the child processes will be more
> important than others. For example all the processes used for browsing
> contexts in
> the foreground tab should probably prefer performance over memory (in
> cases that is
On 07/12/2018 11:08 PM, Randell Jesup wrote:
I do hope that the 100 process figures scenario that was given is a worse case
scenario though...
It's not. Worst case is a LOT worse.
Shutting down threads/threadpools when not needed or off an idle timer
is a Good thing. There may be some perf
On Thu, Jul 12, 2018 at 10:27:13PM +0200, Gabriele Svelto wrote:
On 12/07/2018 22:19, Kris Maglione wrote:
I've actually been thinking on filing a bug to do something similar, to
measure cumulative effects of excess padding in certain types since I
began looking into bug 1460674, and Sylvestre
On Thu, Jul 12, 2018 at 04:08:49PM -0400, Randell Jesup wrote:
I do hope that the 100 process figures scenario that was given is a worse case
scenario though...
It's not. Worst case is a LOT worse.
Shutting down threads/threadpools when not needed or off an idle timer
is a Good thing.
On Thu, Jul 12, 2018 at 08:56:28AM -0700, Andrew McCreight wrote:
On Thu, Jul 12, 2018 at 3:57 AM, Emilio Cobos Álvarez
wrote:
Thanks for doing this!
Just curious, is there a bug on file to measure excess capacity on
nsTArrays and hash tables?
njn looked at that kind of issue at some point
On 12/07/2018 22:19, Kris Maglione wrote:
> I've actually been thinking on filing a bug to do something similar, to
> measure cumulative effects of excess padding in certain types since I
> began looking into bug 1460674, and Sylvestre mentioned that
> clang-analyzer can generate reports on excess
On Thu, Jul 12, 2018 at 12:57:35PM +0200, Emilio Cobos Álvarez wrote:
Thanks for doing this!
Just curious, is there a bug on file to measure excess capacity on
nsTArrays and hash tables?
I don't think so, but it's a good idea.
I've actually been thinking on filing a bug to do something
>I do hope that the 100 process figures scenario that was given is a worse case
>scenario though...
It's not. Worst case is a LOT worse.
Shutting down threads/threadpools when not needed or off an idle timer
is a Good thing. There may be some perf hit since it may mean starting
a thread
On Thu, Jul 12, 2018 at 3:57 AM, Emilio Cobos Álvarez
wrote:
> Thanks for doing this!
>
> Just curious, is there a bug on file to measure excess capacity on
> nsTArrays and hash tables?
>
> WebKit has a bunch of bugs like:
>
> https://bugs.webkit.org/show_bug.cgi?id=186709
>
> Which seem
On Wed, Jul 11, 2018 at 6:25 PM, Karl Tomlinson wrote:
> Is there a guideline that should be used to evaluate what can
> acceptably run in the same process for different sites?
>
This is on me to write. I have been slow at doing so mainly because there's
a lot of "What does X look like and
Thanks for doing this!
Just curious, is there a bug on file to measure excess capacity on
nsTArrays and hash tables?
WebKit has a bunch of bugs like:
https://bugs.webkit.org/show_bug.cgi?id=186709
Which seem relevant.
-- Emilio
On 07/10/2018 08:19 PM, Kris Maglione wrote:
Welcome to
On Thu, Jul 12, 2018 at 11:25 AM, Karl Tomlinson wrote:
> Would it be easier to answer the opposite question? What should
> not run in a shared process? JS is a given. Others?
>
Currently when an exploitable bug is found in content process code,
attackers use JS to weaponize it with an
Is there a guideline that should be used to evaluate what can
acceptably run in the same process for different sites?
I assume the primary goal is to prevent one site from reading
information that should only be available to another site?
There would also be defense-in-depth value from having
On Wed, Jul 11, 2018 at 11:42:01PM +0200, Jean-Yves Avenard wrote:
On 11 Jul 2018, at 10:10 pm, Kris Maglione wrote:
It looks like it will be helpful, but unfortunately won't give us the 2MB
simple arithmetic would suggest. On Windows, at least, (and probably
elsewhere, but need to confirm)
On Wed, Jul 11, 2018 at 11:42:01PM +0200, Jean-Yves Avenard wrote:
> Hi
>
> > On 11 Jul 2018, at 10:10 pm, Kris Maglione wrote:
> > Thanks. Boris added this as a blocker.
> >
> > It looks like it will be helpful, but unfortunately won't give us the 2MB
> > simple arithmetic would suggest. On
Hi
> On 11 Jul 2018, at 10:10 pm, Kris Maglione wrote:
> Thanks. Boris added this as a blocker.
>
> It looks like it will be helpful, but unfortunately won't give us the 2MB
> simple arithmetic would suggest. On Windows, at least, (and probably
> elsewhere, but need to confirm) thread stacks
On Wed, Jul 11, 2018 at 01:49:04PM +0200, Jean-Yves Avenard wrote:
There’s one place where we could gain heaps is in the media stack.
Currently, each content process allocate a thread-pool with at least 8
threads for use with the media decoders, each threads a default stack size of
256kB.
>On 7/11/18 5:42 AM, David Bruant wrote:
>> I've seen this information of 100 content processes in a couple places but
>> i haven't been able to find the rationale for it. How was the 100 number
>> picked?
>
>I believe this is based on telemetry for number of distinct sites involved
>in browsing
On Wed, Jul 11, 2018 at 02:42:11PM +0200, David Bruant wrote:
2018-07-10 20:19 GMT+02:00 Kris Maglione :
The problem is thus: In order for site isolation to work, we need to be
able to run *at least* 100 content processes in an average Firefox session
I've seen this information of 100
On Wed, Jul 11, 2018 at 5:42 AM, David Bruant wrote:
>
>
> * Andrew McCreight created a tool for tracking JS memory usage, and
>> figuring
>> out which scripts and objects are responsible for how much of it
>> (https://bugzil.la/1463569).
>>
> How often is this code run? Is there a place to
On 7/11/18 5:42 AM, David Bruant wrote:
I've seen this information of 100 content processes in a couple places but
i haven't been able to find the rationale for it. How was the 100 number
picked?
I believe this is based on telemetry for number of distinct sites
involved in browsing sessions.
Thanks Kris for all this information and the beginning of the first issue
of this newsletter!
2018-07-10 20:19 GMT+02:00 Kris Maglione :
> The problem is thus: In order for site isolation to work, we need to be
> able to run *at least* 100 content processes in an average Firefox session
I've
Hi
That’s great info, thank you.
There’s one place where we could gain heaps is in the media stack.
Currently, each content process allocate a thread-pool with at least 8 threads
for use with the media decoders, each threads a default stack size of 256kB.
>Welcome to the first edition of the Fission MemShrink newsletter.[1]
This is awesome and critical.
I'll note (and many of you know this well) that in addition to getting
rid of allocations (or making them lazy), another primary solution is to
move data out of the Content processes, and into the
Welcome to the first edition of the Fission MemShrink newsletter.[1]
In this edition, I'll sum up what the project is, and why it matters to you.
In subsequent editions, I'll give updates on progress that we've made, and
areas that we'll need to focus on next.[2]
The Fission MemShrink
37 matches
Mail list logo
