Every process apparently gets a fully-committed 4mb JS stack on Linux. This isn't much of a problem when we have one process which usually takes up 300+mb of RAM. But when we have many processes each taking up < 30mb of RAM, 4mb per process is huge. Assuming we're not using much of this stack (I expect we're not), this is by far the largest single piece of waste I see in B2G . ISTM that a simple thing to do would be to madvise(MADV_DONTNEED) the unused portions of the stack periodically (e.g. on GC) and then let them get faulted in if and when we need them. We may not want this on our desktop Linux builds.  attachment 668326 [details]. Save this file, decompress it, and open it via the "read reports from file" button at the bottom of about:memory.
We should do bug 798510 first so we get an idea how much of the stack we're actually using.
bug 798510 suggests that we actually use very little stack space. So I guess this is WONTFIX until such a time as we correctly observe ourselves using lots of space for stacks.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
(In reply to Justin Lebar [:jlebar] from comment #1) > We should do bug 798510 first so we get an idea how much of the stack we're > actually using. Sounds to me like that one should block bug 797189 then ;-)
> Sounds to me like that one should block bug 797189 then ;-) It does, transitively through this bug. And since this bug was wontfixed, that bug no longer logically blocks slim-fast. I don't see what the problem is, but you have my blessing to modify the metadata to your pleasing. :)
You need to log in before you can comment on or make changes to this bug.