I recently landed bug 664341 into mozilla-central, which adds an API to specify the amount of virtual address space reserved for the thread stacks of nsIThreads. The new API looks like this:
extern NS_COM_GLUE NS_METHOD
NS_NewThread(nsIThread **result,
nsIRunnable *initialEvent = nsnull,
PRUint32 stackSize = nsIThreadManager::DEFAULT_STACK_SIZE);
extern NS_COM_GLUE NS_METHOD
NS_NewThread(nsIThread **result,
nsIRunnable *initialEvent = nsnull,
PRUint32 stackSize = nsIThreadManager::DEFAULT_STACK_SIZE);
The default stack size is the default for whatever platform your running on, so behaviour is unchanged for existing uses of NS_NewThread.
This new API is important, as x86 Linux by default reserves 8MB of virtual address space per thread stack. Windows and OSX use 1MB and 64KB respectively. If you have a lot of threads, their stacks can hog the virtual address space, and malloc will fail; we had at least one media mochitest that could fail in this way.
If you have code that creates threads, you should consider using this API. It's an easy way to reduce perceived memory usage.
I've also recently concluded a major refactoring of the media playback engine in Firefox. This reduces the number of threads required to play <audio> and <video> elements by roughly one third. We now only require two threads per playing media element (plus one extra thread for sound playback on Linux at least until bug 623444 lands and we can refactor to take advantage of that). Media elements which are paused now shut down their threads where possible, resulting in lower overall memory usage. If you have a page with 100 <audio> elements on it, you no longer have 300 threads lying around using up virtual address space!
2 comments:
Have we thought about reporting these stacks in about:memory?
Looks like the memshrink gods have spoken, and thread stacks are indeed wanted in about:memory:
https://bugzilla.mozilla.org/show_bug.cgi?id=674818
Post a Comment