We seem to allocate js_AllocStack() which causes a 8224 allocation and this lives only for 0.005 sec. Overall memory churned: 37 * 8224 = 304288 Can we allocate once and reuse or maybe even use the stack

Looks like this happens more than 100 times churning about 1MB

This is 100 times over the course of startup?

We pretty much have to use js_AllocStack in order to do JS calls. Perhaps the JS engine is too aggresive in reclaiming this space?

The stack is allocated from an arena pool, cx->stackPool, so there should be good reuse. dp, can you show the stack backtrace for a typical (or all) free call(s) that gives back to the malloc heap the memory allocated to cx->stackPool by nsXPCWrappedJSClass::CallMethod's js_AllocStack? /be

This is from spacetrace.

Boris, yes this is 100+ times for starting up the browser with default profile and mozilla.org start page

dp, I need the matching free stacks -- not all js_AllocStack calls should malloc, either, but those that do should not be matched by a free on the matching js_FreeStack call -- arena pools hang onto arenas until they're "Finished" by a call to JS_GC on that cx. IOW, do the free calls that match these mallocs come from JS_GC, or from somewhere else? /be

Space trace shows only the stack traces for allocation. Garrett is there any way you can harness from the trace-malloc log, the matching free call.

A callsite is recorded in the trace-malloc log, but it is that of the original malloc callsite if I recall. you'll need to modify xpcom/base/nsTraceMalloc.c to record the correct free callstack. this is a little more involved than simply changed spacetrace; there may even be dependencies on the callstack of the free being the same hash item as the callstack of the malloc in the tool, but I would have to check or wait till it broke and then fix it.

Should this be assigned to the JS Engine component and team member?

Taking. /be

I have a spacetrace log for compose window (mozilla.exe -compose), with 5 lines of text typed in it. see screen shot later. Data on my machine showed that we chug through 11MB (11,702,752 Bytes) of heap by js_AllocRawStack

Missed 0.9.8, but thanks for the space-trace -- I'll look tonight. Just cleaning my buglist now. /be

All platforms.

malloc is not inherently evil, but the churn here seems high. Probably our 8192 byte actual param (http://lxr.mozilla.org/mozilla/search?string=gStackSize) passed to JS_NewContext by the DOM is too large. I don't have time to look at this right now, but I'll try to find some soon. This may slip into 1.0. /be

This can't block 0.9.9. I'll look into dropping gStackSize for 1.0, if not inventing an adaptive size scheme. /be

reduce churn --> reduce malloc overhead --> reduce data footprint nsbeta1 :-)

shaver, you want this one? If not, can you lay any utilization-measuring patch you may have on us here? /be

Moving out a bit. The js1.5 release (after an rc5 release candidate) should come off off the 1.0 branch on or before 1.0.2 freezing, I say. The trunk and branch should be in sync for js/src/js*.[chmt]* and build files. /be

Fixing TM. /be

adt: nsbeta1-

This needs to be re-measured and stuff. /be

From log: "brendan@mozilla.org 2004-04-19 22:25 PDT Target Milestone mozilla1.7alpha Future" 1.7 is now past alpha. "The future" has arrived. ?ing it to put on radar.(In reply to comment #23) > This needs to be re-measured and stuff. > > /be Was it ever re-measured "and stuff"? From log: "brendan@mozilla.org 2004-04-19 22:25 PDT Target Milestone mozilla1.7alpha Future" 1.7 is now past alpha. "The future" has arrived. ?ing it to put on radar.

> Was it ever re-measured "and stuff"? No. If it had been, the results would be in the bug. Feel free to remeasure and post the results here. Otherwise, please stop spamming bugs with uses comments.

Before nominating this as blocking an alpha, which is unlikely for a non-crash, non-dataloss bug, someone should measure. What bz said, too. /be

I meant to change the "target milestone", but did a blocking flag by mistake. At least I did the latest. Just doing some bug QA work while I had a second. Sorry for any inconvenience.

Sasquatch, please don't change Target Milestone, that belongs to the assignee or a designated helper. Have you read the bugzilla docs and etiquette guides? /be

(In reply to comment #28) > Sasquatch, please don't change Target Milestone, that belongs to the assignee or > a designated helper. Have you read the bugzilla docs and etiquette guides? > > /be All is OK, it wouldn't allow that either. So, how else would one get one of these old bugs out of mothballs and either put to rest or worked on? Just trying to contribute by doing some bug QA here.

Sasquatch: it's unfortunately hard to test these bugs without added instrumentation, and without using tools such as spacetrace. Maybe that's a tool you could use, though -- IIRC it requires 1GB RAM to run well on the same machine! /be

Disowning formally, obvious I've been a deadbeat dad to this bug. Someone else will have to take up the cause. For Mozilla 2 we will use Tamarin underneath of SpiderMonkey, and avoid XPConnected DOM altogether. /be

Could dup forward to bug 408113, or dup that against this. Crowder, are you able to make time to implemnet the idea I sketched there? It would be good to get the simplest patch along those lines in soon. /be

Duping forward, since that bug has more love in the way of patches