478741 - Investigate optimal stack size of Windows CE

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[Alan Lee]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; ko; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 (.NET CLR 3.5.30729)
Build Identifier: 

Build flag for stack size need to be added for WinCE build.
If it is not specified default value of 1MB is reserved for every thread.
With less than 32MB of virtual memory per process this is waste of valuable memory and cause memory problems.

For a fix add the following line in 'arm-wince-gcc.c'

args[i++] = "/STACK:65536"; 

Although in most cases it is more than enough,
we need to evaluate if specifying 64KB is sufficient.

Please refer to my previous post for more information (link below).
http://groups.google.com/group/mozilla.dev.platforms.mobile/browse_thread/thread/2d57f60c3f0b5f47#

Reproducible: Always

Comment 1

[Alan Lee]

One more comment,
There is one thing I didn't realize when writing the post in the above link.
That was dll's over 64KB are allocated in a new slot with WM 6.1.
Here is a link with good details about WM6.1 virtual memory.

http://bolingconsulting.com/blog/?p=4

I'll try to run some tests to verify how this works for Fennec on WinMo.
Anyway above comment about stack size is still valid.

Comment 2

[Brad Lassey [:blassey] (use needinfo?)]

fwiw visual studio 9 defaults to 64K for the stack size.  It would be reasonable for us to do the same or similar. 

It would be nice to get some data on how big our stack gets during a typical run.

Comment 3

[Alan Lee]

I got a measurement of memory usage of xulrunner.exe on my device (using devhealth.exe) but it is NOT an accurate one since xulrunner.exe was not running properly on my device.
I'm attaching the logs as 'fennec_testrun_mem.txt'.
(My device is a Korean version of Samsung i780).
Xulrunner.exe process was running but nothing really happened.
I assume it didn't start properly and maybe was hanging without terminating.
I emphasize that this is not an typical run and the data is probably far from a successful run. I'm just sharing this info since it might give us some ideas of how things are.

1. You could verify that reserved memory for a single stack is quite large (1MB).
2. I see total 5 stacks with 1 stack taking up 54KB, others were fairly small.
I expect there will be more threads thus more stacks if xulrunner.exe would run successfully. But there being stack coming close to 64KB, setting the stack size to 64KB globally might cause stack overflow for some threads.
If it was a native Win32 App, I would set the stack size to 64KB globally and create particular threads with larger stack size. 
3. There is over 3MB
4. You could also see xul.dll and some other dlls loaded properly in virtual memory slot 60.

I also tried running with stack size set to 64KB but xulrunner.exe didn't run successfully.
Maybe building a release version might help but I didn't have enough time to try it.

Comment 4

[Alan Lee]

Attachment: devhealth dump of virtual memory during (failed ?) fennec test run

Comment 5

[Brad Lassey [:blassey] (use needinfo?)]

I think we decided against changing the stack size, if there are any other arguments reopen this bug

Comment 6

[Alan Lee]

Brad,
I posted the bug.
I apologize for not following upon it.
I would appreciate it if you could give me a brief explanation of why you decided not to change the stack size.
Thank you.

Alan.