Skip to content
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

Closed
euglv opened this issue Apr 24, 2016 · 20 comments
Closed

Question about v8 --stack_size #6360

euglv opened this issue Apr 24, 2016 · 20 comments

Comments

@euglv
Copy link

@euglv euglv commented Apr 24, 2016

  • 5.11.0:
  • 64bit:
  • Windows Server 2012-r2:

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)?

@Fishrock123
Copy link
Member

@Fishrock123 Fishrock123 commented Apr 24, 2016

@euglv Please try looking at node --v8-options.

--stack_size (default size of stack region v8 is allowed to use (in kBytes))

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.

@ChALkeR
Copy link
Member

@ChALkeR ChALkeR commented Apr 24, 2016

It's a v8 feature.

node --help:

…
  --v8-options          print v8 command line options
…

node --v8-options:

…
  --stack_size (default size of stack region v8 is allowed to use (in kBytes))
        type: int  default: 984
…
@ChALkeR ChALkeR closed this Apr 24, 2016
@Fishrock123 Fishrock123 changed the title Lack of documentation for stack-size CLI parameter Question about v8 --stack_size Apr 24, 2016
@Fishrock123
Copy link
Member

@Fishrock123 Fishrock123 commented Apr 24, 2016

Reopening, as I don't have info to answer the other questions, but other folks here might.

@Fishrock123 Fishrock123 reopened this Apr 24, 2016
@ChALkeR ChALkeR added the V8 Engine label Apr 24, 2016
@mscdex
Copy link
Contributor

@mscdex mscdex commented Apr 24, 2016

FWIW v8 5.0 (in node v6) has tail call optimizations behind a flag (--es-staging) if recursion is the issue here.

@ChALkeR
Copy link
Member

@ChALkeR ChALkeR commented Apr 24, 2016

Note: it is still highly not recommended to use flagged features in production.

@euglv
Copy link
Author

@euglv euglv commented Apr 24, 2016

Thank you for answers.
So this is the only documentation about this option:

--stack_size (default size of stack region v8 is allowed to use (in kBytes))
type: int default: 984

Yes, cause of "stack overflow" error was recursion in my case. And I definitely need recursion, and recursion steps are definitely limited.
If I run node with --stack-size=1000 - still get "stack overflow" error, but fore some reason if I run node with --stack-size=1200 - in some step of a recursion node crushes silently, without any error at all.
When I searched internet about this issue I saw answers, that on linux node has one particular possiblestack-size limit, under windows - another.
No mention in documentation how large could be stack-size option, and on what it depends.

Finally I figured out how to get rid of "stack overflow" error, without touching stack-size option at all:

var recurciveFunc = function(params) {
  /* Some code */
  /* ..... */
  setTimeout(function(){  recurciveFunc(params)  }, 0);
}

If I wrap recursion call in setTimeout - "stack overflow" error disappears.

@mscdex
Copy link
Contributor

@mscdex mscdex commented Apr 25, 2016

@euglv You could also use process.nextTick() or setImmediate() instead of setTimeout(..., 0)

@ChALkeR
Copy link
Member

@ChALkeR ChALkeR commented Apr 25, 2016

@euglv

And I definitely need recursion

Just a reminder: any recursion could be converted to an iterative algorithm. So you probably don't. 😉

@bnoordhuis
Copy link
Member

@bnoordhuis bnoordhuis commented Apr 25, 2016

--stack_size controls what V8 thinks is the stack size, not the actual stack size. It's for overriding the default when the default doesn't match reality. V8's estimate is fairly conservative, there is normally no need to touch it.

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.

@louisbuchbinder
Copy link

@louisbuchbinder louisbuchbinder commented Sep 15, 2017

@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 stack_limit, but we want to be sure that the change will be stable in production. Thank you.

@addaleax
Copy link
Member

@addaleax addaleax commented Sep 15, 2017

@louisbuchbinder You might need to talk to your OS for that; if it’s about Linux and maybe other POSIXes, ulimit -s should be helpful.

@louisbuchbinder
Copy link

@louisbuchbinder louisbuchbinder commented Sep 15, 2017

Oh interesting thank you for the quick response!

@louisbuchbinder
Copy link

@louisbuchbinder louisbuchbinder commented Sep 15, 2017

One more question here. Is there any way to get/print the value of the stack_size option during runtime? In the v8 docs I can see a method to set options from a string, but no mention of getting that value. I am using node6. Thank you!

@bnoordhuis
Copy link
Member

@bnoordhuis bnoordhuis commented Sep 16, 2017

@louisbuchbinder

$ node --v8-options | grep -A1 -w stack_size
  --stack_size (default size of stack region v8 is allowed to use (in kBytes))
        type: int  default: 984
@gireeshpunathil
Copy link
Member

@gireeshpunathil gireeshpunathil commented Sep 16, 2017

looks like a good requirement for node-report
==== 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

@louisbuchbinder
Copy link

@louisbuchbinder louisbuchbinder commented Sep 16, 2017

@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 node-report, however I am unfamiliar with that tool.

@bnoordhuis
Copy link
Member

@bnoordhuis bnoordhuis commented Sep 18, 2017

@louisbuchbinder You cannot, not reliably. You could scan process.execArgv but that won't help if the application calls v8.setFlagsFromString('--stack_size=1234').

@gireeshpunathil
Copy link
Member

@gireeshpunathil gireeshpunathil commented Sep 18, 2017

@bnoordhuis - correct me if I am missing something: a call to pthread_attr_getstacksize is all what is required to get it right? Is it that not all the threads in the process obey --stack_size? or are there other reasons?

@bnoordhuis
Copy link
Member

@bnoordhuis bnoordhuis commented Sep 18, 2017

@gireeshpunathil
Copy link
Member

@gireeshpunathil gireeshpunathil commented Sep 18, 2017

o! thanks. I never thought that was what --stack_size is. So the actual thread stack size is different and is controlled natively, while this controls some V8's internal structure for managing code size, method calls etc.

So agree, that measuring the value this flag neither is reliable, nor meaningful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants
You can’t perform that action at this time.