Closed Bug 115973 Opened 18 years ago Closed 12 years ago

1MB churned by nsXPCWrappedJSClass::CallMethod


(Core :: JavaScript Engine, defect, P2)






(Reporter: dp, Unassigned)



(Keywords: js1.5, perf)


(2 files)

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
Summary: 304188 bytes churned in 37 calls to nsXPCWrappedJSClass::CallMethod+1338(138889) → 1MB churned by nsXPCWrappedJSClass::CallMethod
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?

This is from spacetrace.
Boris, yes this is 100+ times for starting up the browser with default profile
and 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?

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

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?

Assignee: dbradley → brendan
Keywords: mozilla0.9.8
Priority: -- → P2
Target Milestone: --- → mozilla0.9.8
Component: XPConnect → Javascript Engine
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
Blocks: 7251, 71668
Keywords: perf
Missed 0.9.8, but thanks for the space-trace -- I'll look tonight.  Just
cleaning my buglist now.

Target Milestone: mozilla0.9.8 → mozilla0.9.9
All platforms.
OS: Windows 2000 → All
Hardware: PC → All
Blocks: 92580
Priority: P2 → P1
malloc is not inherently evil, but the churn here seems high.  Probably our 8192
byte actual param (
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.

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

Keywords: mozilla0.9.9mozilla1.0
Target Milestone: mozilla0.9.9 → mozilla1.0
reduce churn --> reduce malloc overhead --> reduce data footprint
nsbeta1  :-)
Keywords: nsbeta1
Priority: P1 → P2
shaver, you want this one?  If not, can you lay any utilization-measuring patch
you may have on us here?

Target Milestone: mozilla1.0 → mozilla1.0.1
Blocks: 149801
Keywords: mozilla1.0.1mozilla1.2
Target Milestone: mozilla1.0.1 → mozilla1.0.2
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.

Fixing TM.

Target Milestone: mozilla1.0.2 → mozilla1.3beta
Target Milestone: mozilla1.3beta → mozilla1.4beta
Target Milestone: mozilla1.4beta → mozilla1.5alpha
adt: nsbeta1-
Keywords: nsbeta1nsbeta1-
Target Milestone: mozilla1.5alpha → mozilla1.6alpha
Target Milestone: mozilla1.6alpha → mozilla1.7alpha
This needs to be re-measured and stuff.

Target Milestone: mozilla1.7alpha → Future
From log: " 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: " 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.

Flags: blocking1.8a4?
> 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.

Flags: blocking1.8a4?
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?

(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

QA Contact: pschwartau → general
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.

Assignee: brendan → nobody
Blocks: js-perf
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.

Depends on: 408113
Duping forward, since that bug has more love in the way of patches
Closed: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 408113
You need to log in before you can comment on or make changes to this bug.