Last Comment Bug 573631 - trace malloc for x86_64 Mac OS X builds is too slow
: trace malloc for x86_64 Mac OS X builds is too slow
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: XPCOM (show other bugs)
: Trunk
: x86_64 Mac OS X
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks: 558496 581077 674647
  Show dependency treegraph
 
Reported: 2010-06-21 17:02 PDT by Josh Aas
Modified: 2011-12-13 10:39 PST (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
sample 1, app startup (30.59 KB, text/plain)
2010-06-21 17:10 PDT, Josh Aas
no flags Details
sample 2, network load (1.06 KB, text/plain)
2010-06-21 17:13 PDT, Josh Aas
no flags Details
sample 2, network load, expanded (17.24 KB, text/plain)
2010-06-21 17:23 PDT, Josh Aas
no flags Details

Description Josh Aas 2010-06-21 17:02:01 PDT
I believe the cause for bug 558496 is that trace malloc runs incredibly slowly on x86_64 Mac OS X builds. The slowdown appears to be worse than 10x, possibly 20x or so, leading to the 3600 second timeout. I can reproduce this behavior locally on a Mac Pro, and the problem goes away on my machine and the Mac Mini build slave if I run tests without trace malloc.
Comment 1 Josh Aas 2010-06-21 17:10:44 PDT
Created attachment 452906 [details]
sample 1, app startup

This sample was taken during app startup and as expected, 'findClosestSymbol' dominates.
Comment 2 Josh Aas 2010-06-21 17:13:05 PDT
Created attachment 452908 [details]
sample 2, network load

This sample was taken during the first network load, after:

localhost - - [21/Jun/2010 20:01:08] "GET /bloatcycle.html HTTP/1.1" 200 -
Comment 3 Josh Aas 2010-06-21 17:23:04 PDT
Created attachment 452913 [details]
sample 2, network load, expanded

Same as sample 2 but with the stack expanded.
Comment 4 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2010-06-21 17:23:38 PDT
Is findClosestSymbol called from within dladdr?
Comment 5 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2010-06-21 17:28:07 PDT
So one possibility here is that the calltree locking is much too fine-grained; I think I've been concerned about that in the past.
Comment 6 Josh Aas 2010-06-21 17:39:56 PDT
(In reply to comment #4)
> Is findClosestSymbol called from within dladdr?

Yes:

dyld ImageLoaderMachOCompressed::findClosestSymbol(void const*, void const**) const
dyld dladdr
XUL NS_DescribeCodeAddress
Comment 7 Armen Zambrano [:armenzg] - Engineering productivity 2011-10-04 07:35:46 PDT
Anyone that can be working on this?

We are trying to move the 10.5 leak builds to be run on 10.6 minis in bug 674647 and we are hitting this problem.
Comment 8 Rafael Ávila de Espíndola (:espindola) (not reading bugmail) 2011-11-01 11:20:25 PDT
I think this was fixed with bug 696281. Can someone check?
Comment 9 Armen Zambrano [:armenzg] - Engineering productivity 2011-11-03 09:27:20 PDT
We seemed to have fixed the slowness (few good runs showed only 1 minute on running alive_tests2) but we have resuscitated bug 558496.
Comment 10 Rafael Ávila de Espíndola (:espindola) (not reading bugmail) 2011-12-13 10:39:23 PST
This was fixed in https://hg.mozilla.org/mozilla-central/rev/c9a74f4ee1f7

Note You need to log in before you can comment on or make changes to this bug.