374872 - [cycle collector] freeze/pause after clicking on a link?

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[(not reading, please use [e-mail] instead)]

[places] brief freeze/pause after clicking on a link?

I'm not sure what's going on, but I'm running a places bookmarks build (with the bookmarks sidebar open, in case that matters), and for a while I think I've noticed a brief freeze/pause after I click on links.

nothing more yet, but I'll keep an eye out.

but my gut tells me it is places.

Comment 1

[(not reading, please use [e-mail] instead)]

I'm frequently seeing about a 40% cpu usage on my debug windows trunk build.

graydon, could this be the culprit?

 	ntdll.dll!7c918893() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
 	ntdll.dll!7c918238() 	
 	ntdll.dll!7c911c76() 	
 	ntdll.dll!7c91825d() 	
 	ntdll.dll!7c912270() 	
 	ntdll.dll!7c911596() 	
 	ntdll.dll!7c9106eb() 	
 	ntdll.dll!7c911538() 	
 	ntdll.dll!7c911596() 	
 	ntdll.dll!7c910e91() 	
 	ntdll.dll!7c9106eb() 	
>	msvcr80d.dll!_heap_alloc_base(unsigned int size=1083)  Line 105 + 0x28 bytes	C
 	msvcr80d.dll!_heap_alloc_dbg(unsigned int nSize=1047, int nBlockUse=1, const char * szFileName=0x00000000, int nLine=0)  Line 409 + 0x9 bytes	C++
 	msvcr80d.dll!_nh_malloc_dbg(unsigned int nSize=1047, int nhFlag=0, int nBlockUse=1, const char * szFileName=0x00000000, int nLine=0)  Line 266 + 0x15 bytes	C++
 	msvcr80d.dll!malloc(unsigned int nSize=1047)  Line 152 + 0x15 bytes	C++
 	js3250.dll!JS_ArenaAllocate(JSArenaPool * pool=0x021ed9c8, unsigned int nb=16)  Line 158 + 0xa bytes	C
 	js3250.dll!SprintAlloc(Sprinter * sp=0x0012f1a8, unsigned int nb=9)  Line 374 + 0x5a bytes	C
 	js3250.dll!QuoteString(Sprinter * sp=0x0012f1a8, JSString * str=0x00d4da30, unsigned long quote=0)  Line 503 + 0x13 bytes	C
 	js3250.dll!js_QuoteString(JSContext * cx=0x021ed978, JSString * str=0x00d4da30, unsigned short quote=0)  Line 576 + 0x12 bytes	C
 	js3250.dll!js_ValueToPrintable(JSContext * cx=0x021ed978, long v=13949492, JSString * (JSContext *, long)* v2sfun=0x004718bb)  Line 2640 + 0xf bytes	C
 	js3250.dll!js_AtomToPrintableString(JSContext * cx=0x021ed978, JSAtom * atom=0x00d51d18)  Line 63 + 0x15 bytes	C
 	xpc3250.dll!nsXPConnect::Traverse(void * p=0x03f17200, nsCycleCollectionTraversalCallback & cb={...})  Line 688 + 0x19 bytes	C++
 	xpcom_core.dll!GraphWalker::NoteScriptChild(unsigned int langID=2, void * child=0x03f17200)  Line 770	C++
 	xpc3250.dll!nsXPConnect::Traverse(void * p=0x03f171a0, nsCycleCollectionTraversalCallback & cb={...})  Line 769	C++
 	xpcom_core.dll!GraphWalker::Walk(void * s0=0x3fafbdf0)  Line 802 + 0x30 bytes	C++
 	xpcom_core.dll!nsCycleCollector::MarkRoots()  Line 859 + 0x21 bytes	C++
 	xpcom_core.dll!nsCycleCollector::Collect(unsigned int aTryCollections=1)  Line 1678	C++
 	xpcom_core.dll!nsCycleCollector_collect()  Line 1912	C++
 	gklayout.dll!nsJSContext::Notify(nsITimer * timer=0x3e6ba240)  Line 3177	C++
 	xpcom_core.dll!nsTimerImpl::Fire()  Line 387	C++
 	xpcom_core.dll!nsTimerEvent::Run()  Line 458	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0012f68c)  Line 483	C++
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x00b9c520, int mayWait=1)  Line 225 + 0x16 bytes	C++
 	gkwidget.dll!nsBaseAppShell::Run()  Line 154 + 0xc bytes	C++
 	tkitcmps.dll!nsAppStartup::Run()  Line 171 + 0x1c bytes	C++
 	xul.dll!XRE_main(int argc=1, char * * argv=0x00b997d8, const nsXREAppData * aAppData=0x004036b4)  Line 2860 + 0x25 bytes	C++
 	firefox.exe!main(int argc=1, char * * argv=0x00b997d8)  Line 61 + 0x13 bytes	C++
 	firefox.exe!__tmainCRTStartup()  Line 586 + 0x19 bytes	C
 	firefox.exe!mainCRTStartup()  Line 403	C
 	kernel32.dll!7c816fd7() 	
 	ntdll.dll!7c91056d() 	

Comment 2

[Graydon Hoare :graydon]

Yes. See this thread:
http://groups.google.ca/group/mozilla.dev.performance/browse_thread/thread/e85e4111fe1b9782

The short summary is that there's a lot of debug code in the cycle collector, so when you run a debug build it gets a lot slower. There's also a lot of "safety" code that's not #ifdef DEBUG. So we can degrade the safety code to #ifdef DEBUG and/or some of the #ifdef DEBUG code to simply not be built at all, depending on how slow it feels. 

Comment 3

[(not reading, please use [e-mail] instead)]

graydon, thanks for link to dbaron's post.  (I'm relieved this performance issue isn't places related, and it was known.)

for me, on my 1.6 Ghz / 2GB Windows XP laptop, it makes the debug browser pretty slow.  Nearly unusable at times. 

note, this is my debug build, so #ifdef DEBUG isn't going to help me, so perhaps we could do #ifdef DEBUG_XPCOM_CYCLE_COLLECTOR or something else?

Comment 4

[(not reading, please use [e-mail] instead)]

Attachment: patch per graydon

Comment 5

[(not reading, please use [e-mail] instead)]

this should be affecting scott and david when debugging the trunk tbird builds, too.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Peter, should we take something like that patch (perhaps without "graydon" in it and some DEBUG_username stuff to define the relevant macro for people who care)?

Comment 7

[Peter Van der Beken [:peterv]]

I've been using DEBUG_CC (see patch in bug 373693). I'm fine with ifdef'ing this.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Let's do it, then.  ;)

Comment 9

[Peter Van der Beken [:peterv]]

Comment on attachment 260066 [details] [diff] [review]
patch per graydon

I'll land this tomorrow with ifdef DEBUG_CC

Comment 10

[Peter Van der Beken [:peterv]]

Checked that patch in, let's file remaining issues as separate bugs.

Comment 11

[Franz]

Please take a look at

http://www.heise.de/security/news/foren/go.shtml?forum_id=118386&list=1&hs=0&e=all

Any of the following actions performed on a link

b) left click
a) right click
c) middle click

seem to freeze firefox for about one second. Within that time nothing else is
updated and you cannot switch tabs.

System: Lx i386, FF 1.5.0.12, javascript off.
Workaround: disable style sheets

A different forum does not show this behavior:

http://www.heise.de/newsticker/foren/go.shtml?forum_id=118441&list=1&hs=0&e=all

Any suggestions?

Comment 12

[Ryan VanderMeulen [:RyanVM]]

This bug is related to a regression for a feature which exists only on the Gecko 1.9 trunk (what will become Firefox 3.0). Whatever issue you're having with 1.5.0.12 is completely unrelated to this bug. Please file a new bug for it.