realloc stack use under O0 for x86_64
D'Alessandro, Luke K
ldalessa at indiana.edu
Wed Mar 25 18:29:23 PDT 2015
> On Mar 25, 2015, at 9:11 PM, Mike Hommey <mh at glandium.org> wrote:
> On Thu, Mar 26, 2015 at 12:57:28AM +0000, D'Alessandro, Luke K wrote:
>>> On Mar 25, 2015, at 8:34 PM, Jason Evans <jasone at canonware.com> wrote:
>>> On Mar 25, 2015, at 11:48 AM, D'Alessandro, Luke K <ldalessa at indiana.edu> wrote:
>>>> We have a lightweight threading system where we are using very small stacks, on the order of 8-32k. We depend on jemalloc for scalable allocation.
>>>> When we compile jemalloc for debugging purposes, we see realloc using a large amount of stack space:
>>>> 0000000000070e48 <realloc>:
>>>> 70e48: 55 push %rbp
>>>> 70e49: 48 89 e5 mov %rsp,%rbp
>>>> 70e4c: 53 push %rbx
>>>> 70e4d: 48 81 ec 68 62 00 00 sub $0x6268,%rsp
>>> Wow, that's far more stack space than I can imagine an explanation for. What version of jemalloc is this happening with, which OS, compiler, etc.?
>> Hi Jason,
>> This was with
>> jemalloc: 562d266511053a51406e91c78eba640cb46ad9c8
>> ./configure CFLAGS="-O0 -g”
> Add "-Dalways_inline=" and you'll avoid all the functions that are
> forced to be inlined. That might help you.
This completely eliminates the issue, I can run with 8k stacks without any problem. It must be some really weird interaction with inlining and looping? I checked with llvm and it is stack allocating over 500 variables in that from with -O0, with symbol names that look like they come from inlining.
I attached the entry block for -O0 and -O3 if anyone wants to take a look at it.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2769 bytes
More information about the jemalloc-discuss