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

Comments

Projects
None yet
8 participants
@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

This comment has been minimized.

Show comment
Hide comment
@Fishrock123

Fishrock123 Apr 24, 2016

Member

@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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@ChALkeR

ChALkeR Apr 24, 2016

Member

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
…
Member

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 from Lack of documentation for stack-size CLI parameter to Question about v8 --stack_size Apr 24, 2016

@Fishrock123

This comment has been minimized.

Show comment
Hide comment
@Fishrock123

Fishrock123 Apr 24, 2016

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex Apr 24, 2016

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@ChALkeR

ChALkeR Apr 24, 2016

Member

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

Member

ChALkeR commented Apr 24, 2016

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

@euglv

This comment has been minimized.

Show comment
Hide comment
@euglv

euglv 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.

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

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex Apr 25, 2016

Contributor

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

Contributor

mscdex commented Apr 25, 2016

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

@ChALkeR

This comment has been minimized.

Show comment
Hide comment
@ChALkeR

ChALkeR Apr 25, 2016

Member

@euglv

And I definitely need recursion

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Apr 25, 2016

Member

--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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@louisbuchbinder

louisbuchbinder 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.

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

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Sep 15, 2017

Member

@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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@louisbuchbinder

louisbuchbinder Sep 15, 2017

Oh interesting thank you for the quick response!

louisbuchbinder commented Sep 15, 2017

Oh interesting thank you for the quick response!

@louisbuchbinder

This comment has been minimized.

Show comment
Hide comment
@louisbuchbinder

louisbuchbinder 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!

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

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Sep 16, 2017

Member

@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
Member

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

This comment has been minimized.

Show comment
Hide comment
@gireeshpunathil

gireeshpunathil Sep 16, 2017

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@louisbuchbinder

louisbuchbinder 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.

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

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Sep 18, 2017

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@gireeshpunathil

gireeshpunathil Sep 18, 2017

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
Member

bnoordhuis commented Sep 18, 2017

@gireeshpunathil

This comment has been minimized.

Show comment
Hide comment
@gireeshpunathil

gireeshpunathil Sep 18, 2017

Member

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.

Member

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