Investigate optimal stack size of Windows CE

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
10 years ago
9 years ago

People

(Reporter: coderiff, Unassigned)

Tracking

({mobile})

Trunk
ARM
Windows Mobile 6 Professional
mobile

Details

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
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
(Reporter)

Updated

10 years ago
OS: Other → Windows Mobile 6 Professional
Hardware: Other → ARM
(Reporter)

Updated

10 years ago
Keywords: mobile
(Reporter)

Comment 1

10 years ago
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.
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.
(Reporter)

Comment 3

10 years ago
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.
(Reporter)

Comment 4

10 years ago
Created attachment 363123 [details]
devhealth dump of virtual memory during (failed ?) fennec test run

Updated

10 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted-fennec1.0?
Summary: Stack size for WinCE build needs to be configured (default is too large) → Investigate optimal stack size of Windows CE
I think we decided against changing the stack size, if there are any other arguments reopen this bug
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Flags: wanted-fennec1.0?
Resolution: --- → WONTFIX
(Reporter)

Comment 6

9 years ago
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.
You need to log in before you can comment on or make changes to this bug.