-
Notifications
You must be signed in to change notification settings - Fork 29.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question about v8 --stack_size #6360
Comments
@euglv Please try looking at
In normal practice you shouldn't need to adjust this afaik, mind outlining what you are doing? It sounds like you may have recusing tail calls, which are not currently optimized by v8. |
It's a v8 feature.
|
Reopening, as I don't have info to answer the other questions, but other folks here might. |
FWIW v8 5.0 (in node v6) has tail call optimizations behind a flag ( |
Note: it is still highly not recommended to use flagged features in production. |
Thank you for answers.
Yes, cause of "stack overflow" error was recursion in my case. And I definitely need recursion, and recursion steps are definitely limited. Finally I figured out how to get rid of "stack overflow" error, without touching
If I wrap recursion call in |
@euglv You could also use |
Just a reminder: any recursion could be converted to an iterative algorithm. So you probably don't. 😉 |
If you set it higher than the actual limit, the process gets killed (on UNIX) by a SIGBUS signal when it exceeds the limit. I'll close, I think that answers the question. |
@bnoordhuis Would you mind answering how we can determine the "actual stack size"? Is this simply the unused heap? Or some other machine characteristic? We are considering modifying the |
@louisbuchbinder You might need to talk to your OS for that; if it’s about Linux and maybe other POSIXes, |
Oh interesting thank you for the quick response! |
One more question here. Is there any way to get/print the value of the |
|
looks like a good requirement for node-report Event: SIGUSR2, location: "SignalDumpInterruptCallback"
Filename: node-report.20170517.125940.57943.001.txt
Dump event time: 2017/05/17 12:59:40
Module load time: 2017/05/17 12:57:49
Process ID: 57943
Thread stack size: 8092M >> new
Command line: node -r node-report --stack_size=8286208 --max-old-space-size=200 cpu.js
Node.js version: v7.10.0
(ares: 1.10.1-DEV, cldr: 30.0.3, http_parser: 2.7.0, icu: 58.2, modules: 51,
openssl: 1.0.2k, tz: 2016j, unicode: 9.0, uv: 1.11.0, v8: 5.5.372.43, zlib: 1.2.11) /cc @ rnchamberlain |
@bnoordhuis Thank you, but I am trying to print the current value in the process that I have updated. Unfortunately I do not have control of the invocation of my script (that is done by our platform helper process). I am looking for a way to confirm/test that the value I expect to see has actually been updated. It looks like @gireeshpunathil might be on to something with |
@louisbuchbinder You cannot, not reliably. You could scan |
@bnoordhuis - correct me if I am missing something: a call to |
o! thanks. I never thought that was what So agree, that measuring the value this flag neither is reliable, nor meaningful. |
Perfect, my solution: |
I can't find any documentation about
--stack-size=XXX
node.js CLI parameter.But this parameter seems to have some effect, increasing it to some value eliminates "stack overflow" error. But increasing it more further makes node.js unstable. (It just quits in some time without any error)
So my questions are:
Is
XXX
in bytes, kilobytes or megabytes?What is the default value when this parameter is omitted?
What is the minimum and maximum possible values for this parameter?
How operating system (linux/windows) and platform (32bit/64bit) affects this parameter (maximum, minimum, default value)?
The text was updated successfully, but these errors were encountered: