On 7/27/20 12:48 PM, Jan Hubicka wrote:
Yes, I verified that.
I guess I can try
to do some profiling since this problem did not show on Firefox (that i
find odd given that Firefox is just about half of the size).
Yep, I'm also surprised about it.
Perhaps glibc has some stupid limit in realloc that makes it to behave
in a silly way for very large arrays?
Dunno :P
Seems like glibc issue. On my debian testing box:
hubicka@lomikamen-jh:~$ cat t.c
#include <stdlib.h>
main(int argc, char **argv)
{
char *a = malloc (1);
int i,n=atoi(argv[1]);
for (i=2;i<n;i++)
a = realloc (a,i);
}
hubicka@lomikamen-jh:~$ time ./a.out 1000000000
real 0m10.057s
user 0m9.696s
sys 0m0.356s
And kunlun (which is a lot faster than my 2013 buldozer):
abuild@kunlun:~> time ./a.out 1000000000
real 0m59.808s
user 0m58.703s
sys 0m1.080s
It runs for me in:
$ time ./a.out 1000000000
real 0m10.048s
user 0m9.742s
sys 0m0.305s
Note that there may be an interleaving load on the machine.
Perf says:
55.40% a.out libc-2.26.so [.] realloc
36.01% a.out a.out [.] realloc@plt
4.98% a.out libc-2.26.so [.] mremap_chunk
3.60% a.out a.out [.] main
while on my machine I see:
real 0m4.998s
user 0m4.947s
sys 0m0.050s
54.49% a.out libc-2.31.so [.] realloc
37.63% a.out libc-2.31.so [.] mremap_chunk
3.72% a.out a.out [.] realloc@plt
Martin
GDB stops at:
(gdb) bt
#0 0x00007ffff7e70bfe in realloc () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00005555555550bf in main ()
on debian while:
(gdb) bt
#0 0x00007ffff7e7d6d0 in mem2mem_check () from /lib64/libc.so.6
#1 0x00007ffff7e81c7d in realloc_check () from /lib64/libc.so.6
#2 0x00005555555550bf in main ()
on kunlun.
Perhaps someone enabled some cool security harnessing feature without
much of benchmarking :) (but even debian numbers seems like they can be
improved)
Honza
Martin
Honza
Martin
