Eliot,
Thanks for the info, that's good to know. I probably should have been explicit in that I am only bumping it up this high to troubleshoot a rather annoying startup bug in my code. When it crashes as a result of the stack overflow the trace is pretty useless (iirc, about 1/2 a page of INVALID REFERENCE so I'm mostly flying blind.) Bumping up the limit is allowing me to get a better view of where things are going wrong and I plan to drop back once I've resolved it.
Thanks, Phil
On Jun 12, 2017 4:43 PM, "Eliot Miranda" eliot.miranda@gmail.com wrote:
Hi Phil,
On Jun 12, 2017, at 12:50 PM, Phil B pbpublist@gmail.com wrote:
In trying to troubleshoot an issue, I needed to bump up the stackpages
parameter. On 64-bit Linux, a value of 600 worked but 1000 segfaulted so I was just wondering what the limit(s) are for it?
There are no explicit limits. The set fault you're seeing is as a result of the stack pages being allocated on the c stack. When the number is high the stack overflows and boom.
A word to the wise: too high a value and scavenging performance falls (stack pages are implicitly roots into new space), and become performance falls (all activations in stack space are scanned post become to avoid a read barrier on inst var fetch).
The default value was 192, a value chosen to exceed qwaq server process usage, but both at Cadence and in Spur profiling we found that was not a good value and pulled it back to 64 (IIRC).
I'm curious as to why are you exploring such high values.