5 ms·

Stack space is virtually free and it’s just a few instructions to put the value on the stack. Regardless, this increased overhead is very small compared to the

Stack space is virtually free and it’s just a few instructions to put the value on the stack. Regardless, this increased overhead is very small compared to the total overhead of making a function call in the first place. The place to eke out every last cycle is the tight loop, which should not include function calls anyway.

hinkley 6y ago
> Stack space is virtually free On machines with 64 bit addressing. There are lots of things that don’t work so well on 32 bit or 16 bit OSes that we have to unlearn. There have been a couple times where I thought about trying to catalog all of the things I think I know about a piece of hardware, software or even a single library, so that I can challenge my own assumptions when a major release comes out. Never have gotten around to it.
- CyberRabbi 6y ago
  > On machines with 64 bit addressing. There are lots of things that don’t work so well on 32 bit or 16 bit OSes that we have to unlearn. Stack space is virtually free on 32 bit systems as well. V8 is not designed for or portable to 16-bit or 8-bit systems, so while your point is interesting, it’s irrelevant here.
  - hinkley 6y ago
    > Stack space is virtually free on 32 bit systems as well. How do you figure that, given we’ve had quite a bit of time wrestling with 2G memory limitations and how those interact badly with multithreading?
    - CyberRabbi 6y ago
      For general applications and as a matter of good practice, stack depth practically never gets deep enough to make a dent in 2GB. If your stack is reaching a significant proportion of 2GB you are seriously doing something wrong and it’s likely other parts of your application will start breaking as well.
      - hinkley 6y ago
        I think it's pretty clear that I'm saying "this has not been my experience." It's not 'my stack'. It's all stacks. Each thread has a stack. They are all in your 1.2-2GB address space. If you're not using a Global Interpreter Lock'ed language, you could easily end up with hundreds of threads for production code. And the more you try to dedupe work, the more threads you are likely to end up with.
    - topspin 6y ago
      > How do you figure that Given 32 bit words you'll see 4 bytes per call for parameter counts. A call stack 100 calls deep will incur 400 extra bytes of stack space overhead; less than half a KiB. Along the way all extra 'arguments adaptor frames' are eliminated, so the net is even smaller. That doesn't look like a problem. If you're 100 calls deep and you blow out the stack because it's 400 bytes larger you have other issues.
      - hinkley 6y ago
        I'm not talking about word size on the stack. I'm talking about 2GB available for heap, plus reserved space for all stacks. Most programming languages need the stack to be a linear set of addresses. So you figure out what the max reasonable stack size is for a given thread, and you pre-allocate that address space. Which means even if the stack stays shallow, you can't use those addresses for heap. If you increase the average case for your call stack size, then the available heap shrinks. That's why I'm saying we are doing this now, even though in theory this knowledge has been available to us for a very long time. Nearly everything is 64 bit now, and even in the JVM where they carve 2 bits off for parallel mark and sweep, there are still oceans of extra address space for us to 'waste'.
        topspin 6y ago
        > and you pre-allocate that address space The increase in stack usage is highly unlikely to require more space than the default 'reasonable' stack size already being allocated for threads in 32b environments where one is likely to be operating v8; typically the defaults are already pretty generous. Unless the default thread stack size allocation actually has to be increased to accommodate the modest growth caused by the change then there is zero impact on available heap.

hinkley 6y ago

> Stack space is virtually free On machines with 64 bit addressing. There are lots of things that don’t work so well on 32 bit or 16 bit OSes that we have to unlearn. There have been a couple times where I thought about trying to catalog all of the things I think I know about a piece of hardware, software or even a single library, so that I can challenge my own assumptions when a major release comes out. Never have gotten around to it.

CyberRabbi 6y ago
> On machines with 64 bit addressing. There are lots of things that don’t work so well on 32 bit or 16 bit OSes that we have to unlearn. Stack space is virtually free on 32 bit systems as well. V8 is not designed for or portable to 16-bit or 8-bit systems, so while your point is interesting, it’s irrelevant here.
- hinkley 6y ago
  > Stack space is virtually free on 32 bit systems as well. How do you figure that, given we’ve had quite a bit of time wrestling with 2G memory limitations and how those interact badly with multithreading?
  - CyberRabbi 6y ago
    For general applications and as a matter of good practice, stack depth practically never gets deep enough to make a dent in 2GB. If your stack is reaching a significant proportion of 2GB you are seriously doing something wrong and it’s likely other parts of your application will start breaking as well.
    - hinkley 6y ago
      I think it's pretty clear that I'm saying "this has not been my experience." It's not 'my stack'. It's all stacks. Each thread has a stack. They are all in your 1.2-2GB address space. If you're not using a Global Interpreter Lock'ed language, you could easily end up with hundreds of threads for production code. And the more you try to dedupe work, the more threads you are likely to end up with.
  - topspin 6y ago
    > How do you figure that Given 32 bit words you'll see 4 bytes per call for parameter counts. A call stack 100 calls deep will incur 400 extra bytes of stack space overhead; less than half a KiB. Along the way all extra 'arguments adaptor frames' are eliminated, so the net is even smaller. That doesn't look like a problem. If you're 100 calls deep and you blow out the stack because it's 400 bytes larger you have other issues.
    - hinkley 6y ago
      I'm not talking about word size on the stack. I'm talking about 2GB available for heap, plus reserved space for all stacks. Most programming languages need the stack to be a linear set of addresses. So you figure out what the max reasonable stack size is for a given thread, and you pre-allocate that address space. Which means even if the stack stays shallow, you can't use those addresses for heap. If you increase the average case for your call stack size, then the available heap shrinks. That's why I'm saying we are doing this now, even though in theory this knowledge has been available to us for a very long time. Nearly everything is 64 bit now, and even in the JVM where they carve 2 bits off for parallel mark and sweep, there are still oceans of extra address space for us to 'waste'.
      - topspin 6y ago
        > and you pre-allocate that address space The increase in stack usage is highly unlikely to require more space than the default 'reasonable' stack size already being allocated for threads in 32b environments where one is likely to be operating v8; typically the defaults are already pretty generous. Unless the default thread stack size allocation actually has to be increased to accommodate the modest growth caused by the change then there is zero impact on available heap.