Re: can we optimize STACK_DEPTH_SLOP

Greg Stark <stark(at)mit(dot)edu> writes:
> Fwiw here's the pmap info from burbot (Linux Sparc64):
> 136 48 48 rw--- [ stack ]
> 136 48 48 rw--- [ stack ]
> 136 48 48 rw--- [ stack ]
> 136 48 48 rw--- [ stack ]
> 136 56 56 rw--- [ stack ]
> 136 80 80 rw--- [ stack ]
> 136 96 96 rw--- [ stack ]
> 136 112 112 rw--- [ stack ]
> 136 112 112 rw--- [ stack ]
> 576 576 576 rw--- [ stack ]
> 2056 2056 2056 rw--- [ stack ]

> I'm actually a bit confused how to interpret these numbers. This
> appears to be an 8kB pagesize architecture so is that 576*8kB or over
> 5MB of stack for the regexp test?

No, pmap specifies that its outputs are measured in kilobytes. So this
is by and large the same as what I'm seeing on x86_64, again with the
caveat that the recursive regex routines seem to vary all over the place
in terms of stack consumption.

> But we don't know if there are any
> check_stack_depth calls in that call tree?

The regex recursion definitely does have check_stack_depth calls in it
(since commit b63fc2877). But what we're trying to measure here is the
worst-case stack depth regardless of any check_stack_depth calls. That's
a ceiling on what we might need to set STACK_DEPTH_SLOP to --- probably a
very loose ceiling, but I don't want to err on the side of underestimating
it. I wouldn't consider either the regex or errors tests as needing to
bound STACK_DEPTH_SLOP, since we know that most of their consumption is
from recursive code that contains check_stack_depth calls. But it's
useful to look at those depths just as a sanity check that we're getting
valid numbers.

regards, tom lane