* [PATCH 1/3] Support new mallinfo2 function. @ 2020-09-01 12:31 Martin Liška 2020-09-01 12:32 ` [PATCH 2/3] Use MiB unit when displaying memory allocation Martin Liška ` (3 more replies) 0 siblings, 4 replies; 16+ messages in thread From: Martin Liška @ 2020-09-01 12:31 UTC (permalink / raw) To: GCC Patches; +Cc: Jan Hubicka [-- Attachment #1: Type: text/plain, Size: 331 bytes --] Hey. I've just applied to patches to glibc introducing a new mallinfo2 function. Limitation of the current function mallinfo is usage of int type which overflows for allocation > 2GB. The patch adds configure detection and usage of the new one. And it prints heap usage in MiB. Ready to be installed after tests? Thanks, Martin [-- Attachment #2: 0001-Support-new-mallinfo2-function.patch --] [-- Type: text/x-patch, Size: 4699 bytes --] From 031ae63018a32c9ac10fab58f4a6c8b5a9166060 Mon Sep 17 00:00:00 2001 From: Martin Liska <mliska@suse.cz> Date: Tue, 1 Sep 2020 14:14:45 +0200 Subject: [PATCH 1/3] Support new mallinfo2 function. gcc/ChangeLog: * config.in: Regenerate. * configure: Likewise. * configure.ac: Detect for mallinfo2. * ggc-common.c (defined): Use it and display info in MiB. * system.h: Handle also HAVE_MALLINFO2. --- gcc/config.in | 16 ++++++++++++++-- gcc/configure | 4 ++-- gcc/configure.ac | 4 ++-- gcc/ggc-common.c | 12 +++++++++--- gcc/system.h | 2 +- 5 files changed, 28 insertions(+), 10 deletions(-) diff --git a/gcc/config.in b/gcc/config.in index 478e74fac02..1832c112ed9 100644 --- a/gcc/config.in +++ b/gcc/config.in @@ -983,13 +983,19 @@ #endif -/* Define to 1 if we found a declaration for 'mallinfo', otherwise define to - 0. */ +/* Define to 1 if we found a declaration for 'mallinfo */ #ifndef USED_FOR_TARGET #undef HAVE_DECL_MALLINFO #endif +/* Define to 1 if we found a declaration for 'mallinfo2', otherwise define to + 0. */ +#ifndef USED_FOR_TARGET +#undef HAVE_DECL_MALLINFO2 +#endif + + /* Define to 1 if we found a declaration for 'malloc', otherwise define to 0. */ #ifndef USED_FOR_TARGET @@ -1665,6 +1671,12 @@ #endif +/* Define to 1 if you have the `mallinfo2' function. */ +#ifndef USED_FOR_TARGET +#undef HAVE_MALLINFO2 +#endif + + /* Define to 1 if you have the <malloc.h> header file. */ #ifndef USED_FOR_TARGET #undef HAVE_MALLOC_H diff --git a/gcc/configure b/gcc/configure index 0f7a8dbe0f9..b8b9bd3505b 100755 --- a/gcc/configure +++ b/gcc/configure @@ -10120,7 +10120,7 @@ fi for ac_func in times clock kill getrlimit setrlimit atoq \ popen sysconf strsignal getrusage nl_langinfo \ gettimeofday mbstowcs wcswidth mmap setlocale \ - clearerr_unlocked feof_unlocked ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked putchar_unlocked putc_unlocked madvise mallinfo + clearerr_unlocked feof_unlocked ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked putchar_unlocked putc_unlocked madvise mallinfo mallinfo2 do : as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh` ac_fn_cxx_check_func "$LINENO" "$ac_func" "$as_ac_var" @@ -11549,7 +11549,7 @@ fi done -for ac_func in mallinfo +for ac_func in mallinfo, mallinfo2 do ac_tr_decl=`$as_echo "HAVE_DECL_$ac_func" | $as_tr_cpp` { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $ac_func is declared" >&5 diff --git a/gcc/configure.ac b/gcc/configure.ac index 0f11238c19f..18640fdb8a5 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -1408,7 +1408,7 @@ define(gcc_UNLOCKED_FUNCS, clearerr_unlocked feof_unlocked dnl AC_CHECK_FUNCS(times clock kill getrlimit setrlimit atoq \ popen sysconf strsignal getrusage nl_langinfo \ gettimeofday mbstowcs wcswidth mmap setlocale \ - gcc_UNLOCKED_FUNCS madvise mallinfo) + gcc_UNLOCKED_FUNCS madvise mallinfo mallinfo2) if test x$ac_cv_func_mbstowcs = xyes; then AC_CACHE_CHECK(whether mbstowcs works, gcc_cv_func_mbstowcs_works, @@ -1488,7 +1488,7 @@ gcc_AC_CHECK_DECLS(getrlimit setrlimit getrusage, , ,[ #endif ]) -gcc_AC_CHECK_DECLS(mallinfo, , ,[ +gcc_AC_CHECK_DECLS([mallinfo, mallinfo2], , ,[ #include "ansidecl.h" #include "system.h" #ifdef HAVE_MALLOC_H diff --git a/gcc/ggc-common.c b/gcc/ggc-common.c index 94da02f1185..f6be5472bd5 100644 --- a/gcc/ggc-common.c +++ b/gcc/ggc-common.c @@ -1008,13 +1008,19 @@ ggc_prune_overhead_list (void) } } -/* Return memory used by heap in kb, 0 if this info is not available. */ +/* Print memory used by heap in MiB if this info is not available. */ void report_heap_memory_use () { -#ifdef HAVE_MALLINFO +#if defined(HAVE_MALLINFO) || defined(HAVE_MALLINFO2) +#ifdef HAVE_MALLINFO2 + #define MALLINFO_FN mallinfo2 +#else + #define MALLINFO_FN mallinfo +#endif if (!quiet_flag) - fprintf (stderr," {heap %luk}", (unsigned long)(mallinfo().arena / 1024)); + fprintf (stderr," {heap %lu MiB}", + (unsigned long) MALLINFO_FN ().arena / ONE_M); #endif } diff --git a/gcc/system.h b/gcc/system.h index 3c543a005d8..4f0482be25d 100644 --- a/gcc/system.h +++ b/gcc/system.h @@ -732,7 +732,7 @@ extern int vsnprintf (char *, size_t, const char *, va_list); #endif #ifdef INCLUDE_MALLOC_H -#ifdef HAVE_MALLINFO +#if defined(HAVE_MALLINFO) || defined(HAVE_MALLINFO2) #include <malloc.h> #endif #endif -- 2.28.0 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 2/3] Use MiB unit when displaying memory allocation. 2020-09-01 12:31 [PATCH 1/3] Support new mallinfo2 function Martin Liška @ 2020-09-01 12:32 ` Martin Liška 2020-09-01 14:04 ` Jan Hubicka 2020-09-01 12:33 ` [PATCH 3/3] Use more ONE_? in GGC functions Martin Liška ` (2 subsequent siblings) 3 siblings, 1 reply; 16+ messages in thread From: Martin Liška @ 2020-09-01 12:32 UTC (permalink / raw) To: GCC Patches; +Cc: Jan Hubicka The patch is about usage of MiB in memory allocation reports. I see it much better readable than values displayed in KiB: Reading object files: tramp3d-v4.o {GC released 1 MiB} {GC 19 MiB -> 19 MiB} {GC 19 MiB} {heap 12 MiB} Reading the symbol table: Merging declarations: {GC released 1 MiB madv_dontneed 0 MiB} {GC 27 MiB -> 27 MiB} {GC 27 MiB} {heap 15 MiB} Reading summaries: <odr> {GC 27 MiB} {heap 15 MiB} <profile_estimate> {GC 27 MiB} {heap 15 MiB} <icf> {GC 27 MiB} {heap 15 MiB} <cp> {GC 27 MiB} {heap 15 MiB} <sra> {GC 27 MiB} {heap 15 MiB} <fnsummary> {GC 30 MiB} {heap 15 MiB} <pure-const> {GC 30 MiB} {heap 15 MiB} {GC 30 MiB} Merging symbols: {heap 15 MiB}Materializing decls: <odr> {heap 15 MiB} <whole-program> {heap 15 MiB} <profile_estimate> {heap 15 MiB} <icf> {heap 15 MiB} <devirt> {heap 15 MiB} <cp> {heap 15 MiB} <sra> {heap 15 MiB} <cdtor> {heap 15 MiB} <fnsummary> {heap 15 MiB} <inline> {heap 15 MiB} <pure-const> {heap 15 MiB} <free-fnsummary> {GC released 1 MiB madv_dontneed 2 MiB} {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} <static-var> {heap 15 MiB} <single-use> {heap 15 MiB} <comdats> {heap 15 MiB} Streaming out {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} ./a.ltrans0.o ( 11257 insns) ./a.ltrans1.o ( 11293 insns) ./a.ltrans2.o ( 8669 insns) ./a.ltrans3.o ( 138934 insns) Thoughts? Thanks, Martin ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/3] Use MiB unit when displaying memory allocation. 2020-09-01 12:32 ` [PATCH 2/3] Use MiB unit when displaying memory allocation Martin Liška @ 2020-09-01 14:04 ` Jan Hubicka 2020-09-02 13:28 ` Martin Liška 0 siblings, 1 reply; 16+ messages in thread From: Jan Hubicka @ 2020-09-01 14:04 UTC (permalink / raw) To: Martin Liška; +Cc: GCC Patches > The patch is about usage of MiB in memory allocation reports. > I see it much better readable than values displayed in KiB: > > Reading object files: tramp3d-v4.o {GC released 1 MiB} {GC 19 MiB -> 19 MiB} {GC 19 MiB} {heap 12 MiB} > Reading the symbol table: > Merging declarations: {GC released 1 MiB madv_dontneed 0 MiB} {GC 27 MiB -> 27 MiB} {GC 27 MiB} {heap 15 MiB} > Reading summaries: <odr> {GC 27 MiB} {heap 15 MiB} <profile_estimate> {GC 27 MiB} {heap 15 MiB} <icf> {GC 27 MiB} {heap 15 MiB} <cp> {GC 27 MiB} {heap 15 MiB} <sra> {GC 27 MiB} {heap 15 MiB} <fnsummary> {GC 30 MiB} {heap 15 MiB} <pure-const> {GC 30 MiB} {heap 15 MiB} {GC 30 MiB} > Merging symbols: {heap 15 MiB}Materializing decls: > <odr> {heap 15 MiB} <whole-program> {heap 15 MiB} <profile_estimate> {heap 15 MiB} <icf> {heap 15 MiB} <devirt> {heap 15 MiB} <cp> {heap 15 MiB} <sra> {heap 15 MiB} <cdtor> {heap 15 MiB} <fnsummary> {heap 15 MiB} <inline> {heap 15 MiB} <pure-const> {heap 15 MiB} <free-fnsummary> {GC released 1 MiB madv_dontneed 2 MiB} {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} <static-var> {heap 15 MiB} <single-use> {heap 15 MiB} <comdats> {heap 15 MiB} > Streaming out {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} ./a.ltrans0.o ( 11257 insns) ./a.ltrans1.o ( 11293 insns) ./a.ltrans2.o ( 8669 insns) ./a.ltrans3.o ( 138934 insns) One problem I see here is that while it is OK for Firefox builds it is bit too coarse for smaller testcases where the memory use is still importnat. I guess we may just print KBs before the large gets too large, just like norton commander does? :) Honza > > Thoughts? > Thanks, > Martin ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/3] Use MiB unit when displaying memory allocation. 2020-09-01 14:04 ` Jan Hubicka @ 2020-09-02 13:28 ` Martin Liška 2020-09-17 21:57 ` Jeff Law 2020-09-22 7:47 ` Christophe Lyon 0 siblings, 2 replies; 16+ messages in thread From: Martin Liška @ 2020-09-02 13:28 UTC (permalink / raw) To: Jan Hubicka; +Cc: GCC Patches [-- Attachment #1: Type: text/plain, Size: 1868 bytes --] On 9/1/20 4:04 PM, Jan Hubicka wrote: >> The patch is about usage of MiB in memory allocation reports. >> I see it much better readable than values displayed in KiB: >> >> Reading object files: tramp3d-v4.o {GC released 1 MiB} {GC 19 MiB -> 19 MiB} {GC 19 MiB} {heap 12 MiB} >> Reading the symbol table: >> Merging declarations: {GC released 1 MiB madv_dontneed 0 MiB} {GC 27 MiB -> 27 MiB} {GC 27 MiB} {heap 15 MiB} >> Reading summaries: <odr> {GC 27 MiB} {heap 15 MiB} <profile_estimate> {GC 27 MiB} {heap 15 MiB} <icf> {GC 27 MiB} {heap 15 MiB} <cp> {GC 27 MiB} {heap 15 MiB} <sra> {GC 27 MiB} {heap 15 MiB} <fnsummary> {GC 30 MiB} {heap 15 MiB} <pure-const> {GC 30 MiB} {heap 15 MiB} {GC 30 MiB} >> Merging symbols: {heap 15 MiB}Materializing decls: >> <odr> {heap 15 MiB} <whole-program> {heap 15 MiB} <profile_estimate> {heap 15 MiB} <icf> {heap 15 MiB} <devirt> {heap 15 MiB} <cp> {heap 15 MiB} <sra> {heap 15 MiB} <cdtor> {heap 15 MiB} <fnsummary> {heap 15 MiB} <inline> {heap 15 MiB} <pure-const> {heap 15 MiB} <free-fnsummary> {GC released 1 MiB madv_dontneed 2 MiB} {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} <static-var> {heap 15 MiB} <single-use> {heap 15 MiB} <comdats> {heap 15 MiB} >> Streaming out {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} ./a.ltrans0.o ( 11257 insns) ./a.ltrans1.o ( 11293 insns) ./a.ltrans2.o ( 8669 insns) ./a.ltrans3.o ( 138934 insns) > > One problem I see here is that while it is OK for Firefox builds it is > bit too coarse for smaller testcases where the memory use is still > importnat. I guess we may just print KBs before the large gets too > large, just like norton commander does? :) Sure, let's do it using SIZE_AMOUNT macro. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed? Thanks, Martin > > Honza >> >> Thoughts? >> Thanks, >> Martin [-- Attachment #2: 0002-Use-SIZE_AMOUNT-macro-for-GGC-memory-allocation-numb.patch --] [-- Type: text/x-patch, Size: 5616 bytes --] From 8826f267175d456121612332b838e41a9542a513 Mon Sep 17 00:00:00 2001 From: Martin Liska <mliska@suse.cz> Date: Wed, 2 Sep 2020 14:30:16 +0200 Subject: [PATCH 2/3] Use SIZE_AMOUNT macro for GGC memory allocation numbers. gcc/ChangeLog: * ggc-common.c (ggc_prune_overhead_list): Use SIZE_AMOUNT. * ggc-page.c (release_pages): Likewise. (ggc_collect): Likewise. (ggc_trim): Likewise. (ggc_grow): Likewise. * timevar.c (timer::print): Likewise. gcc/testsuite/ChangeLog: * g++.dg/ext/timevar1.C: Prune more possible number values. * g++.dg/ext/timevar2.C: Likewise. --- gcc/ggc-common.c | 6 +++--- gcc/ggc-page.c | 15 +++++++-------- gcc/testsuite/g++.dg/ext/timevar1.C | 3 ++- gcc/testsuite/g++.dg/ext/timevar2.C | 3 ++- gcc/timevar.c | 8 ++++---- 5 files changed, 18 insertions(+), 17 deletions(-) diff --git a/gcc/ggc-common.c b/gcc/ggc-common.c index b8782c5824b..50c52fe525b 100644 --- a/gcc/ggc-common.c +++ b/gcc/ggc-common.c @@ -1008,7 +1008,7 @@ ggc_prune_overhead_list (void) } } -/* Print memory used by heap in kb if this info is not available. */ +/* Print memory used by heap if this info is not available. */ void report_heap_memory_use () @@ -1020,7 +1020,7 @@ report_heap_memory_use () #define MALLINFO_FN mallinfo #endif if (!quiet_flag) - fprintf (stderr," {heap %luk}", - (unsigned long) MALLINFO_FN ().arena / ONE_K); + fprintf (stderr, " {heap " PRsa (0) "}", + SIZE_AMOUNT (MALLINFO_FN ().arena)); #endif } diff --git a/gcc/ggc-page.c b/gcc/ggc-page.c index 53b311c2a52..9405f033a7c 100644 --- a/gcc/ggc-page.c +++ b/gcc/ggc-page.c @@ -1164,9 +1164,9 @@ release_pages (void) { fprintf (stderr, " {GC"); if (n1) - fprintf (stderr, " released %luk", (unsigned long)(n1 / 1024)); + fprintf (stderr, " released " PRsa (0), SIZE_AMOUNT (n1)); if (n2) - fprintf (stderr, " madv_dontneed %luk", (unsigned long)(n2 / 1024)); + fprintf (stderr, " madv_dontneed " PRsa (0), SIZE_AMOUNT (n2)); fprintf (stderr, "}"); } } @@ -2208,7 +2208,7 @@ ggc_collect (void) /* Output this later so we do not interfere with release_pages. */ if (!quiet_flag) - fprintf (stderr, " {GC %luk -> ", (unsigned long) allocated / 1024); + fprintf (stderr, " {GC " PRsa (0) " -> ", SIZE_AMOUNT (allocated)); /* Indicate that we've seen collections at this context depth. */ G.context_depth_collections = ((unsigned long)1 << (G.context_depth + 1)) - 1; @@ -2235,7 +2235,7 @@ ggc_collect (void) timevar_pop (TV_GC); if (!quiet_flag) - fprintf (stderr, "%luk}", (unsigned long) G.allocated / 1024); + fprintf (stderr, PRsa (0) "}", SIZE_AMOUNT (G.allocated)); if (GGC_DEBUG_LEVEL >= 2) fprintf (G.debug_file, "END COLLECTING\n"); } @@ -2250,9 +2250,8 @@ ggc_trim () sweep_pages (); release_pages (); if (!quiet_flag) - fprintf (stderr, " {GC trimmed to %luk, %luk mapped}", - (unsigned long) G.allocated / 1024, - (unsigned long) G.bytes_mapped / 1024); + fprintf (stderr, " {GC trimmed to " PRsa (0) ", " PRsa (0) " mapped}", + SIZE_AMOUNT (G.allocated), SIZE_AMOUNT (G.bytes_mapped)); timevar_pop (TV_GC); } @@ -2269,7 +2268,7 @@ ggc_grow (void) else ggc_collect (); if (!quiet_flag) - fprintf (stderr, " {GC %luk} ", (unsigned long) G.allocated / 1024); + fprintf (stderr, " {GC " PRsa (0) "} ", SIZE_AMOUNT (G.allocated)); } void diff --git a/gcc/testsuite/g++.dg/ext/timevar1.C b/gcc/testsuite/g++.dg/ext/timevar1.C index 3f891a50aba..988a6f8543d 100644 --- a/gcc/testsuite/g++.dg/ext/timevar1.C +++ b/gcc/testsuite/g++.dg/ext/timevar1.C @@ -2,7 +2,8 @@ // { dg-options "-ftime-report" } // { dg-allow-blank-lines-in-output 1 } // { dg-prune-output "Time variable" } -// { dg-prune-output " kB" } +// { dg-prune-output "k" } +// { dg-prune-output " 0 " } // { dg-prune-output "checks" } void diff --git a/gcc/testsuite/g++.dg/ext/timevar2.C b/gcc/testsuite/g++.dg/ext/timevar2.C index dd96d45c01e..46c3e1b4794 100644 --- a/gcc/testsuite/g++.dg/ext/timevar2.C +++ b/gcc/testsuite/g++.dg/ext/timevar2.C @@ -1,7 +1,8 @@ // PR c++/57524 // { dg-options "-ftime-report" } // { dg-prune-output "Time variable" } -// { dg-prune-output " kB" } +// { dg-prune-output "k" } +// { dg-prune-output " 0 " } // { dg-prune-output "checks" } namespace detail { diff --git a/gcc/timevar.c b/gcc/timevar.c index a3a882d3204..8fbf5faa4e3 100644 --- a/gcc/timevar.c +++ b/gcc/timevar.c @@ -661,8 +661,8 @@ timer::print_row (FILE *fp, #endif /* HAVE_WALL_TIME */ /* Print the amount of ggc memory allocated. */ - fprintf (fp, "%8u kB (%3.0f%%)", - (unsigned) (elapsed.ggc_mem >> 10), + fprintf (fp, PRsa (6) " (%3.0f%%)", + SIZE_AMOUNT (elapsed.ggc_mem), (total->ggc_mem == 0 ? 0 : (float) elapsed.ggc_mem / total->ggc_mem) * 100); @@ -712,7 +712,7 @@ timer::print (FILE *fp) TIMEVAR. */ m_start_time = now; - fprintf (fp, "\n%-35s%16s%14s%14s%18s\n", "Time variable", "usr", "sys", + fprintf (fp, "\n%-35s%16s%14s%14s%14s\n", "Time variable", "usr", "sys", "wall", "GGC"); if (m_jit_client_items) fputs ("GCC items:\n", fp); @@ -776,7 +776,7 @@ timer::print (FILE *fp) #ifdef HAVE_WALL_TIME fprintf (fp, "%8.2f ", total->wall); #endif - fprintf (fp, "%9u kB\n", (unsigned) (total->ggc_mem >> 10)); + fprintf (fp, PRsa (7) "\n", SIZE_AMOUNT (total->ggc_mem)); if (CHECKING_P || flag_checking) fprintf (fp, "Extra diagnostic checks enabled; compiler may run slowly.\n"); -- 2.28.0 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/3] Use MiB unit when displaying memory allocation. 2020-09-02 13:28 ` Martin Liška @ 2020-09-17 21:57 ` Jeff Law 2020-09-22 7:47 ` Christophe Lyon 1 sibling, 0 replies; 16+ messages in thread From: Jeff Law @ 2020-09-17 21:57 UTC (permalink / raw) To: Martin Liška, Jan Hubicka; +Cc: GCC Patches [-- Attachment #1: Type: text/plain, Size: 3545 bytes --] On 9/2/20 7:28 AM, Martin Liška wrote: > On 9/1/20 4:04 PM, Jan Hubicka wrote: >>> The patch is about usage of MiB in memory allocation reports. >>> I see it much better readable than values displayed in KiB: >>> >>> Reading object files: tramp3d-v4.o {GC released 1 MiB} {GC 19 MiB -> >>> 19 MiB} {GC 19 MiB} {heap 12 MiB} >>> Reading the symbol table: >>> Merging declarations: {GC released 1 MiB madv_dontneed 0 MiB} {GC 27 >>> MiB -> 27 MiB} {GC 27 MiB} {heap 15 MiB} >>> Reading summaries: <odr> {GC 27 MiB} {heap 15 MiB} >>> <profile_estimate> {GC 27 MiB} {heap 15 MiB} <icf> {GC 27 MiB} >>> {heap 15 MiB} <cp> {GC 27 MiB} {heap 15 MiB} <sra> {GC 27 MiB} >>> {heap 15 MiB} <fnsummary> {GC 30 MiB} {heap 15 MiB} <pure-const> >>> {GC 30 MiB} {heap 15 MiB} {GC 30 MiB} >>> Merging symbols: {heap 15 MiB}Materializing decls: >>> <odr> {heap 15 MiB} <whole-program> {heap 15 MiB} >>> <profile_estimate> {heap 15 MiB} <icf> {heap 15 MiB} <devirt> {heap >>> 15 MiB} <cp> {heap 15 MiB} <sra> {heap 15 MiB} <cdtor> {heap 15 MiB} >>> <fnsummary> {heap 15 MiB} <inline> {heap 15 MiB} <pure-const> {heap >>> 15 MiB} <free-fnsummary> {GC released 1 MiB madv_dontneed 2 MiB} {GC >>> trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} <static-var> {heap >>> 15 MiB} <single-use> {heap 15 MiB} <comdats> {heap 15 MiB} >>> Streaming out {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} >>> ./a.ltrans0.o ( 11257 insns) ./a.ltrans1.o ( 11293 insns) >>> ./a.ltrans2.o ( 8669 insns) ./a.ltrans3.o ( 138934 insns) >> >> One problem I see here is that while it is OK for Firefox builds it is >> bit too coarse for smaller testcases where the memory use is still >> importnat. I guess we may just print KBs before the large gets too >> large, just like norton commander does? :) > > Sure, let's do it using SIZE_AMOUNT macro. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? > Thanks, > Martin > >> >> Honza >>> >>> Thoughts? >>> Thanks, >>> Martin > > > 0002-Use-SIZE_AMOUNT-macro-for-GGC-memory-allocation-numb.patch > > From 8826f267175d456121612332b838e41a9542a513 Mon Sep 17 00:00:00 2001 > From: Martin Liska <mliska@suse.cz> > Date: Wed, 2 Sep 2020 14:30:16 +0200 > Subject: [PATCH 2/3] Use SIZE_AMOUNT macro for GGC memory allocation numbers. > > gcc/ChangeLog: > > * ggc-common.c (ggc_prune_overhead_list): Use SIZE_AMOUNT. > * ggc-page.c (release_pages): Likewise. > (ggc_collect): Likewise. > (ggc_trim): Likewise. > (ggc_grow): Likewise. > * timevar.c (timer::print): Likewise. > > gcc/testsuite/ChangeLog: > > * g++.dg/ext/timevar1.C: Prune more possible number values. > * g++.dg/ext/timevar2.C: Likewise. > --- > gcc/ggc-common.c | 6 +++--- > gcc/ggc-page.c | 15 +++++++-------- > gcc/testsuite/g++.dg/ext/timevar1.C | 3 ++- > gcc/testsuite/g++.dg/ext/timevar2.C | 3 ++- > gcc/timevar.c | 8 ++++---- > 5 files changed, 18 insertions(+), 17 deletions(-) > > diff --git a/gcc/ggc-common.c b/gcc/ggc-common.c > index b8782c5824b..50c52fe525b 100644 > --- a/gcc/ggc-common.c > +++ b/gcc/ggc-common.c > @@ -1008,7 +1008,7 @@ ggc_prune_overhead_list (void) > } > } > > -/* Print memory used by heap in kb if this info is not available. */ > +/* Print memory used by heap if this info is not available. */ Seems like the same problem as the prior patch ;-) OK with that nit fixed. jeff [-- Attachment #2: pEpkey.asc --] [-- Type: application/pgp-keys, Size: 1763 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/3] Use MiB unit when displaying memory allocation. 2020-09-02 13:28 ` Martin Liška 2020-09-17 21:57 ` Jeff Law @ 2020-09-22 7:47 ` Christophe Lyon 2020-09-22 8:30 ` Martin Liška 1 sibling, 1 reply; 16+ messages in thread From: Christophe Lyon @ 2020-09-22 7:47 UTC (permalink / raw) To: Martin Liška; +Cc: Jan Hubicka, GCC Patches On Wed, 2 Sep 2020 at 15:29, Martin Liška <mliska@suse.cz> wrote: > > On 9/1/20 4:04 PM, Jan Hubicka wrote: > >> The patch is about usage of MiB in memory allocation reports. > >> I see it much better readable than values displayed in KiB: > >> > >> Reading object files: tramp3d-v4.o {GC released 1 MiB} {GC 19 MiB -> 19 MiB} {GC 19 MiB} {heap 12 MiB} > >> Reading the symbol table: > >> Merging declarations: {GC released 1 MiB madv_dontneed 0 MiB} {GC 27 MiB -> 27 MiB} {GC 27 MiB} {heap 15 MiB} > >> Reading summaries: <odr> {GC 27 MiB} {heap 15 MiB} <profile_estimate> {GC 27 MiB} {heap 15 MiB} <icf> {GC 27 MiB} {heap 15 MiB} <cp> {GC 27 MiB} {heap 15 MiB} <sra> {GC 27 MiB} {heap 15 MiB} <fnsummary> {GC 30 MiB} {heap 15 MiB} <pure-const> {GC 30 MiB} {heap 15 MiB} {GC 30 MiB} > >> Merging symbols: {heap 15 MiB}Materializing decls: > >> <odr> {heap 15 MiB} <whole-program> {heap 15 MiB} <profile_estimate> {heap 15 MiB} <icf> {heap 15 MiB} <devirt> {heap 15 MiB} <cp> {heap 15 MiB} <sra> {heap 15 MiB} <cdtor> {heap 15 MiB} <fnsummary> {heap 15 MiB} <inline> {heap 15 MiB} <pure-const> {heap 15 MiB} <free-fnsummary> {GC released 1 MiB madv_dontneed 2 MiB} {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} <static-var> {heap 15 MiB} <single-use> {heap 15 MiB} <comdats> {heap 15 MiB} > >> Streaming out {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} ./a.ltrans0.o ( 11257 insns) ./a.ltrans1.o ( 11293 insns) ./a.ltrans2.o ( 8669 insns) ./a.ltrans3.o ( 138934 insns) > > > > One problem I see here is that while it is OK for Firefox builds it is > > bit too coarse for smaller testcases where the memory use is still > > importnat. I guess we may just print KBs before the large gets too > > large, just like norton commander does? :) > > Sure, let's do it using SIZE_AMOUNT macro. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > Hi, This change is causing gcc.dg/timevar[12].C to fail randomly, eg: FAIL: g++.dg/ext/timevar1.C -std=gnu++2a (test for excess errors) Excess errors: phase opt and generate : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 50%) 8904 ( 0%) callgraph construction : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 50%) 4096 ( 0%) because SIZE_AMOUNT generates no suffix if the size is < 10k, and those tests now use dg-prune-output "k" and dg-prune-output " 0 " which is not enough. Can you fix this? Thanks Christophe > Ready to be installed? > Thanks, > Martin > > > > > Honza > >> > >> Thoughts? > >> Thanks, > >> Martin > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/3] Use MiB unit when displaying memory allocation. 2020-09-22 7:47 ` Christophe Lyon @ 2020-09-22 8:30 ` Martin Liška 2020-09-22 13:02 ` Marek Polacek 0 siblings, 1 reply; 16+ messages in thread From: Martin Liška @ 2020-09-22 8:30 UTC (permalink / raw) To: Christophe Lyon; +Cc: Jan Hubicka, GCC Patches, Marek Polacek On 9/22/20 9:47 AM, Christophe Lyon wrote: > On Wed, 2 Sep 2020 at 15:29, Martin Liška <mliska@suse.cz> wrote: >> >> On 9/1/20 4:04 PM, Jan Hubicka wrote: >>>> The patch is about usage of MiB in memory allocation reports. >>>> I see it much better readable than values displayed in KiB: >>>> >>>> Reading object files: tramp3d-v4.o {GC released 1 MiB} {GC 19 MiB -> 19 MiB} {GC 19 MiB} {heap 12 MiB} >>>> Reading the symbol table: >>>> Merging declarations: {GC released 1 MiB madv_dontneed 0 MiB} {GC 27 MiB -> 27 MiB} {GC 27 MiB} {heap 15 MiB} >>>> Reading summaries: <odr> {GC 27 MiB} {heap 15 MiB} <profile_estimate> {GC 27 MiB} {heap 15 MiB} <icf> {GC 27 MiB} {heap 15 MiB} <cp> {GC 27 MiB} {heap 15 MiB} <sra> {GC 27 MiB} {heap 15 MiB} <fnsummary> {GC 30 MiB} {heap 15 MiB} <pure-const> {GC 30 MiB} {heap 15 MiB} {GC 30 MiB} >>>> Merging symbols: {heap 15 MiB}Materializing decls: >>>> <odr> {heap 15 MiB} <whole-program> {heap 15 MiB} <profile_estimate> {heap 15 MiB} <icf> {heap 15 MiB} <devirt> {heap 15 MiB} <cp> {heap 15 MiB} <sra> {heap 15 MiB} <cdtor> {heap 15 MiB} <fnsummary> {heap 15 MiB} <inline> {heap 15 MiB} <pure-const> {heap 15 MiB} <free-fnsummary> {GC released 1 MiB madv_dontneed 2 MiB} {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} <static-var> {heap 15 MiB} <single-use> {heap 15 MiB} <comdats> {heap 15 MiB} >>>> Streaming out {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} ./a.ltrans0.o ( 11257 insns) ./a.ltrans1.o ( 11293 insns) ./a.ltrans2.o ( 8669 insns) ./a.ltrans3.o ( 138934 insns) >>> >>> One problem I see here is that while it is OK for Firefox builds it is >>> bit too coarse for smaller testcases where the memory use is still >>> importnat. I guess we may just print KBs before the large gets too >>> large, just like norton commander does? :) >> >> Sure, let's do it using SIZE_AMOUNT macro. >> >> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. >> > > Hi, > > This change is causing gcc.dg/timevar[12].C to fail randomly, eg: > FAIL: g++.dg/ext/timevar1.C -std=gnu++2a (test for excess errors) > Excess errors: > phase opt and generate : 0.00 ( 0%) 0.00 ( 0%) > 0.01 ( 50%) 8904 ( 0%) > callgraph construction : 0.00 ( 0%) 0.00 ( 0%) > 0.01 ( 50%) 4096 ( 0%) > > because SIZE_AMOUNT generates no suffix if the size is < 10k, and those tests > now use dg-prune-output "k" and dg-prune-output " 0 " > which is not enough. > > Can you fix this? Sorry for the breakage. I hope Marek has a fix that he'll install. Martin > > Thanks > > Christophe > >> Ready to be installed? >> Thanks, >> Martin >> >>> >>> Honza >>>> >>>> Thoughts? >>>> Thanks, >>>> Martin >> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/3] Use MiB unit when displaying memory allocation. 2020-09-22 8:30 ` Martin Liška @ 2020-09-22 13:02 ` Marek Polacek 2020-09-22 13:24 ` Marek Polacek 0 siblings, 1 reply; 16+ messages in thread From: Marek Polacek @ 2020-09-22 13:02 UTC (permalink / raw) To: Martin Liška; +Cc: Christophe Lyon, GCC Patches, Jan Hubicka On Tue, Sep 22, 2020 at 10:30:00AM +0200, Martin Liška wrote: > On 9/22/20 9:47 AM, Christophe Lyon wrote: > > On Wed, 2 Sep 2020 at 15:29, Martin Liška <mliska@suse.cz> wrote: > > > > > > On 9/1/20 4:04 PM, Jan Hubicka wrote: > > > > > The patch is about usage of MiB in memory allocation reports. > > > > > I see it much better readable than values displayed in KiB: > > > > > > > > > > Reading object files: tramp3d-v4.o {GC released 1 MiB} {GC 19 MiB -> 19 MiB} {GC 19 MiB} {heap 12 MiB} > > > > > Reading the symbol table: > > > > > Merging declarations: {GC released 1 MiB madv_dontneed 0 MiB} {GC 27 MiB -> 27 MiB} {GC 27 MiB} {heap 15 MiB} > > > > > Reading summaries: <odr> {GC 27 MiB} {heap 15 MiB} <profile_estimate> {GC 27 MiB} {heap 15 MiB} <icf> {GC 27 MiB} {heap 15 MiB} <cp> {GC 27 MiB} {heap 15 MiB} <sra> {GC 27 MiB} {heap 15 MiB} <fnsummary> {GC 30 MiB} {heap 15 MiB} <pure-const> {GC 30 MiB} {heap 15 MiB} {GC 30 MiB} > > > > > Merging symbols: {heap 15 MiB}Materializing decls: > > > > > <odr> {heap 15 MiB} <whole-program> {heap 15 MiB} <profile_estimate> {heap 15 MiB} <icf> {heap 15 MiB} <devirt> {heap 15 MiB} <cp> {heap 15 MiB} <sra> {heap 15 MiB} <cdtor> {heap 15 MiB} <fnsummary> {heap 15 MiB} <inline> {heap 15 MiB} <pure-const> {heap 15 MiB} <free-fnsummary> {GC released 1 MiB madv_dontneed 2 MiB} {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} <static-var> {heap 15 MiB} <single-use> {heap 15 MiB} <comdats> {heap 15 MiB} > > > > > Streaming out {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} ./a.ltrans0.o ( 11257 insns) ./a.ltrans1.o ( 11293 insns) ./a.ltrans2.o ( 8669 insns) ./a.ltrans3.o ( 138934 insns) > > > > > > > > One problem I see here is that while it is OK for Firefox builds it is > > > > bit too coarse for smaller testcases where the memory use is still > > > > importnat. I guess we may just print KBs before the large gets too > > > > large, just like norton commander does? :) > > > > > > Sure, let's do it using SIZE_AMOUNT macro. > > > > > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > > > > > > Hi, > > > > This change is causing gcc.dg/timevar[12].C to fail randomly, eg: > > FAIL: g++.dg/ext/timevar1.C -std=gnu++2a (test for excess errors) > > Excess errors: > > phase opt and generate : 0.00 ( 0%) 0.00 ( 0%) > > 0.01 ( 50%) 8904 ( 0%) > > callgraph construction : 0.00 ( 0%) 0.00 ( 0%) > > 0.01 ( 50%) 4096 ( 0%) > > > > because SIZE_AMOUNT generates no suffix if the size is < 10k, and those tests > > now use dg-prune-output "k" and dg-prune-output " 0 " > > which is not enough. > > > > Can you fix this? > > Sorry for the breakage. I hope Marek has a fix that he'll install. Should be fixed now! Marek ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/3] Use MiB unit when displaying memory allocation. 2020-09-22 13:02 ` Marek Polacek @ 2020-09-22 13:24 ` Marek Polacek 0 siblings, 0 replies; 16+ messages in thread From: Marek Polacek @ 2020-09-22 13:24 UTC (permalink / raw) To: Martin Liška, GCC Patches, Jan Hubicka On Tue, Sep 22, 2020 at 09:02:08AM -0400, Marek Polacek via Gcc-patches wrote: > On Tue, Sep 22, 2020 at 10:30:00AM +0200, Martin Liška wrote: > > On 9/22/20 9:47 AM, Christophe Lyon wrote: > > > On Wed, 2 Sep 2020 at 15:29, Martin Liška <mliska@suse.cz> wrote: > > > > > > > > On 9/1/20 4:04 PM, Jan Hubicka wrote: > > > > > > The patch is about usage of MiB in memory allocation reports. > > > > > > I see it much better readable than values displayed in KiB: > > > > > > > > > > > > Reading object files: tramp3d-v4.o {GC released 1 MiB} {GC 19 MiB -> 19 MiB} {GC 19 MiB} {heap 12 MiB} > > > > > > Reading the symbol table: > > > > > > Merging declarations: {GC released 1 MiB madv_dontneed 0 MiB} {GC 27 MiB -> 27 MiB} {GC 27 MiB} {heap 15 MiB} > > > > > > Reading summaries: <odr> {GC 27 MiB} {heap 15 MiB} <profile_estimate> {GC 27 MiB} {heap 15 MiB} <icf> {GC 27 MiB} {heap 15 MiB} <cp> {GC 27 MiB} {heap 15 MiB} <sra> {GC 27 MiB} {heap 15 MiB} <fnsummary> {GC 30 MiB} {heap 15 MiB} <pure-const> {GC 30 MiB} {heap 15 MiB} {GC 30 MiB} > > > > > > Merging symbols: {heap 15 MiB}Materializing decls: > > > > > > <odr> {heap 15 MiB} <whole-program> {heap 15 MiB} <profile_estimate> {heap 15 MiB} <icf> {heap 15 MiB} <devirt> {heap 15 MiB} <cp> {heap 15 MiB} <sra> {heap 15 MiB} <cdtor> {heap 15 MiB} <fnsummary> {heap 15 MiB} <inline> {heap 15 MiB} <pure-const> {heap 15 MiB} <free-fnsummary> {GC released 1 MiB madv_dontneed 2 MiB} {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} <static-var> {heap 15 MiB} <single-use> {heap 15 MiB} <comdats> {heap 15 MiB} > > > > > > Streaming out {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} ./a.ltrans0.o ( 11257 insns) ./a.ltrans1.o ( 11293 insns) ./a.ltrans2.o ( 8669 insns) ./a.ltrans3.o ( 138934 insns) > > > > > > > > > > One problem I see here is that while it is OK for Firefox builds it is > > > > > bit too coarse for smaller testcases where the memory use is still > > > > > importnat. I guess we may just print KBs before the large gets too > > > > > large, just like norton commander does? :) > > > > > > > > Sure, let's do it using SIZE_AMOUNT macro. > > > > > > > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > > > > > > > > > Hi, > > > > > > This change is causing gcc.dg/timevar[12].C to fail randomly, eg: > > > FAIL: g++.dg/ext/timevar1.C -std=gnu++2a (test for excess errors) > > > Excess errors: > > > phase opt and generate : 0.00 ( 0%) 0.00 ( 0%) > > > 0.01 ( 50%) 8904 ( 0%) > > > callgraph construction : 0.00 ( 0%) 0.00 ( 0%) > > > 0.01 ( 50%) 4096 ( 0%) > > > > > > because SIZE_AMOUNT generates no suffix if the size is < 10k, and those tests > > > now use dg-prune-output "k" and dg-prune-output " 0 " > > > which is not enough. > > > > > > Can you fix this? > > > > Sorry for the breakage. I hope Marek has a fix that he'll install. > > Should be fixed now! Ah, timevar1.C has the same problem. Will fix that one now too. Marek ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 3/3] Use more ONE_? in GGC functions. 2020-09-01 12:31 [PATCH 1/3] Support new mallinfo2 function Martin Liška 2020-09-01 12:32 ` [PATCH 2/3] Use MiB unit when displaying memory allocation Martin Liška @ 2020-09-01 12:33 ` Martin Liška 2020-09-02 13:29 ` Martin Liška 2020-09-01 13:38 ` [PATCH 4/N] Change timevar memory allocation to MiB Martin Liška 2020-09-02 13:28 ` [PATCH 1/3] Support new mallinfo2 function Martin Liška 3 siblings, 1 reply; 16+ messages in thread From: Martin Liška @ 2020-09-01 12:33 UTC (permalink / raw) To: GCC Patches; +Cc: Jan Hubicka [-- Attachment #1: Type: text/plain, Size: 78 bytes --] The last patch is a refactoring using ONE_* macros. Thoughts? Thanks, Martin [-- Attachment #2: 0003-Use-more-ONE_-in-GGC-functions.patch --] [-- Type: text/x-patch, Size: 3836 bytes --] From 999a1969e7325efa0072d0ee893fcb6aa7178997 Mon Sep 17 00:00:00 2001 From: Martin Liska <mliska@suse.cz> Date: Tue, 1 Sep 2020 14:24:20 +0200 Subject: [PATCH 3/3] Use more ONE_? in GGC functions. gcc/ChangeLog: * ggc-common.c (ggc_rlimit_bound): Use ONE_? macros. (ggc_min_expand_heuristic): Likewise. (ggc_min_heapsize_heuristic): Likewise. * ggc-page.c (ggc_collect): Likewise. * system.h (ONE_G): Likewise. --- gcc/ggc-common.c | 16 ++++++++-------- gcc/ggc-page.c | 2 +- gcc/system.h | 1 + 3 files changed, 10 insertions(+), 9 deletions(-) diff --git a/gcc/ggc-common.c b/gcc/ggc-common.c index f6be5472bd5..a22f746e645 100644 --- a/gcc/ggc-common.c +++ b/gcc/ggc-common.c @@ -742,7 +742,7 @@ ggc_rlimit_bound (double limit) appears to be ignored. Ignore such silliness. If a limit this small was actually effective for mmap, GCC wouldn't even start up. */ - && rlim.rlim_cur >= 8 * 1024 * 1024) + && rlim.rlim_cur >= 8 * ONE_M) limit = rlim.rlim_cur; # endif /* RLIMIT_AS or RLIMIT_DATA */ #endif /* HAVE_GETRLIMIT */ @@ -761,7 +761,7 @@ ggc_min_expand_heuristic (void) /* The heuristic is a percentage equal to 30% + 70%*(RAM/1GB), yielding a lower bound of 30% and an upper bound of 100% (when RAM >= 1GB). */ - min_expand /= 1024*1024*1024; + min_expand /= ONE_G; min_expand *= 70; min_expand = MIN (min_expand, 70); min_expand += 30; @@ -776,8 +776,8 @@ ggc_min_heapsize_heuristic (void) double phys_kbytes = physmem_total (); double limit_kbytes = ggc_rlimit_bound (phys_kbytes * 2); - phys_kbytes /= 1024; /* Convert to Kbytes. */ - limit_kbytes /= 1024; + phys_kbytes /= ONE_K; /* Convert to Kbytes. */ + limit_kbytes /= ONE_K; /* The heuristic is RAM/8, with a lower bound of 4M and an upper bound of 128M (when RAM >= 1GB). */ @@ -790,7 +790,7 @@ ggc_min_heapsize_heuristic (void) struct rlimit rlim; if (getrlimit (RLIMIT_RSS, &rlim) == 0 && rlim.rlim_cur != (rlim_t) RLIM_INFINITY) - phys_kbytes = MIN (phys_kbytes, rlim.rlim_cur / 1024); + phys_kbytes = MIN (phys_kbytes, rlim.rlim_cur / ONE_K); } # endif @@ -798,12 +798,12 @@ ggc_min_heapsize_heuristic (void) *next* GC would be within 20Mb of the limit or within a quarter of the limit, whichever is larger. If GCC does hit the data limit, compilation will fail, so this tries to be conservative. */ - limit_kbytes = MAX (0, limit_kbytes - MAX (limit_kbytes / 4, 20 * 1024)); + limit_kbytes = MAX (0, limit_kbytes - MAX (limit_kbytes / 4, 20 * ONE_K)); limit_kbytes = (limit_kbytes * 100) / (110 + ggc_min_expand_heuristic ()); phys_kbytes = MIN (phys_kbytes, limit_kbytes); - phys_kbytes = MAX (phys_kbytes, 4 * 1024); - phys_kbytes = MIN (phys_kbytes, 128 * 1024); + phys_kbytes = MAX (phys_kbytes, 4 * ONE_K); + phys_kbytes = MIN (phys_kbytes, 128 * ONE_K); return phys_kbytes; } diff --git a/gcc/ggc-page.c b/gcc/ggc-page.c index 0a43a7cdc0e..e5988ab1839 100644 --- a/gcc/ggc-page.c +++ b/gcc/ggc-page.c @@ -2184,7 +2184,7 @@ ggc_collect (void) total allocations haven't expanded much since the last collection. */ float allocated_last_gc = - MAX (G.allocated_last_gc, (size_t)param_ggc_min_heapsize * 1024); + MAX (G.allocated_last_gc, (size_t)param_ggc_min_heapsize * ONE_K); /* It is also good time to get memory block pool into limits. */ memory_block_pool::trim (); diff --git a/gcc/system.h b/gcc/system.h index 4f0482be25d..b0f3f1dd019 100644 --- a/gcc/system.h +++ b/gcc/system.h @@ -1237,6 +1237,7 @@ void gcc_stablesort (void *, size_t, size_t, #define ONE_K 1024 #define ONE_M (ONE_K * ONE_K) +#define ONE_G (ONE_K * ONE_M) /* Display a number as an integer multiple of either: - 1024, if said integer is >= to 10 K (in base 2) -- 2.28.0 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 3/3] Use more ONE_? in GGC functions. 2020-09-01 12:33 ` [PATCH 3/3] Use more ONE_? in GGC functions Martin Liška @ 2020-09-02 13:29 ` Martin Liška 2020-09-17 21:57 ` Jeff Law 0 siblings, 1 reply; 16+ messages in thread From: Martin Liška @ 2020-09-02 13:29 UTC (permalink / raw) To: GCC Patches; +Cc: Jan Hubicka [-- Attachment #1: Type: text/plain, Size: 279 bytes --] On 9/1/20 2:33 PM, Martin Liška wrote: > The last patch is a refactoring using ONE_* macros. > > Thoughts? > Thanks, > Martin There's rebassed version of the patch. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed? Thanks, Martin [-- Attachment #2: 0003-Use-ONE_-macros.patch --] [-- Type: text/x-patch, Size: 3820 bytes --] From 5cefff607077503794a387b612585604c2b3d0f0 Mon Sep 17 00:00:00 2001 From: Martin Liska <mliska@suse.cz> Date: Wed, 2 Sep 2020 14:34:21 +0200 Subject: [PATCH 3/3] Use ONE_? macros. gcc/ChangeLog: * ggc-common.c (ggc_rlimit_bound): Use ONE_? macro. (ggc_min_expand_heuristic): Likewise. (ggc_min_heapsize_heuristic): Likewise. * ggc-page.c (ggc_collect): Likewise. * system.h (ONE_G): Likewise. --- gcc/ggc-common.c | 16 ++++++++-------- gcc/ggc-page.c | 2 +- gcc/system.h | 1 + 3 files changed, 10 insertions(+), 9 deletions(-) diff --git a/gcc/ggc-common.c b/gcc/ggc-common.c index 50c52fe525b..c21886861f0 100644 --- a/gcc/ggc-common.c +++ b/gcc/ggc-common.c @@ -742,7 +742,7 @@ ggc_rlimit_bound (double limit) appears to be ignored. Ignore such silliness. If a limit this small was actually effective for mmap, GCC wouldn't even start up. */ - && rlim.rlim_cur >= 8 * 1024 * 1024) + && rlim.rlim_cur >= 8 * ONE_M) limit = rlim.rlim_cur; # endif /* RLIMIT_AS or RLIMIT_DATA */ #endif /* HAVE_GETRLIMIT */ @@ -761,7 +761,7 @@ ggc_min_expand_heuristic (void) /* The heuristic is a percentage equal to 30% + 70%*(RAM/1GB), yielding a lower bound of 30% and an upper bound of 100% (when RAM >= 1GB). */ - min_expand /= 1024*1024*1024; + min_expand /= ONE_G; min_expand *= 70; min_expand = MIN (min_expand, 70); min_expand += 30; @@ -776,8 +776,8 @@ ggc_min_heapsize_heuristic (void) double phys_kbytes = physmem_total (); double limit_kbytes = ggc_rlimit_bound (phys_kbytes * 2); - phys_kbytes /= 1024; /* Convert to Kbytes. */ - limit_kbytes /= 1024; + phys_kbytes /= ONE_K; /* Convert to Kbytes. */ + limit_kbytes /= ONE_K; /* The heuristic is RAM/8, with a lower bound of 4M and an upper bound of 128M (when RAM >= 1GB). */ @@ -790,7 +790,7 @@ ggc_min_heapsize_heuristic (void) struct rlimit rlim; if (getrlimit (RLIMIT_RSS, &rlim) == 0 && rlim.rlim_cur != (rlim_t) RLIM_INFINITY) - phys_kbytes = MIN (phys_kbytes, rlim.rlim_cur / 1024); + phys_kbytes = MIN (phys_kbytes, rlim.rlim_cur / ONE_K); } # endif @@ -798,12 +798,12 @@ ggc_min_heapsize_heuristic (void) *next* GC would be within 20Mb of the limit or within a quarter of the limit, whichever is larger. If GCC does hit the data limit, compilation will fail, so this tries to be conservative. */ - limit_kbytes = MAX (0, limit_kbytes - MAX (limit_kbytes / 4, 20 * 1024)); + limit_kbytes = MAX (0, limit_kbytes - MAX (limit_kbytes / 4, 20 * ONE_K)); limit_kbytes = (limit_kbytes * 100) / (110 + ggc_min_expand_heuristic ()); phys_kbytes = MIN (phys_kbytes, limit_kbytes); - phys_kbytes = MAX (phys_kbytes, 4 * 1024); - phys_kbytes = MIN (phys_kbytes, 128 * 1024); + phys_kbytes = MAX (phys_kbytes, 4 * ONE_K); + phys_kbytes = MIN (phys_kbytes, 128 * ONE_K); return phys_kbytes; } diff --git a/gcc/ggc-page.c b/gcc/ggc-page.c index 9405f033a7c..07e108f3e9d 100644 --- a/gcc/ggc-page.c +++ b/gcc/ggc-page.c @@ -2184,7 +2184,7 @@ ggc_collect (void) total allocations haven't expanded much since the last collection. */ float allocated_last_gc = - MAX (G.allocated_last_gc, (size_t)param_ggc_min_heapsize * 1024); + MAX (G.allocated_last_gc, (size_t)param_ggc_min_heapsize * ONE_K); /* It is also good time to get memory block pool into limits. */ memory_block_pool::trim (); diff --git a/gcc/system.h b/gcc/system.h index 4f0482be25d..b0f3f1dd019 100644 --- a/gcc/system.h +++ b/gcc/system.h @@ -1237,6 +1237,7 @@ void gcc_stablesort (void *, size_t, size_t, #define ONE_K 1024 #define ONE_M (ONE_K * ONE_K) +#define ONE_G (ONE_K * ONE_M) /* Display a number as an integer multiple of either: - 1024, if said integer is >= to 10 K (in base 2) -- 2.28.0 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 3/3] Use more ONE_? in GGC functions. 2020-09-02 13:29 ` Martin Liška @ 2020-09-17 21:57 ` Jeff Law 0 siblings, 0 replies; 16+ messages in thread From: Jeff Law @ 2020-09-17 21:57 UTC (permalink / raw) To: Martin Liška, GCC Patches; +Cc: Jan Hubicka [-- Attachment #1: Type: text/plain, Size: 846 bytes --] On 9/2/20 7:29 AM, Martin Liška wrote: > On 9/1/20 2:33 PM, Martin Liška wrote: >> The last patch is a refactoring using ONE_* macros. >> >> Thoughts? >> Thanks, >> Martin > > There's rebassed version of the patch. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? > Thanks, > Martin > > 0003-Use-ONE_-macros.patch > > From 5cefff607077503794a387b612585604c2b3d0f0 Mon Sep 17 00:00:00 2001 > From: Martin Liska <mliska@suse.cz> > Date: Wed, 2 Sep 2020 14:34:21 +0200 > Subject: [PATCH 3/3] Use ONE_? macros. > > gcc/ChangeLog: > > * ggc-common.c (ggc_rlimit_bound): Use ONE_? macro. > (ggc_min_expand_heuristic): Likewise. > (ggc_min_heapsize_heuristic): Likewise. > * ggc-page.c (ggc_collect): Likewise. > * system.h (ONE_G): Likewise. OK jeff [-- Attachment #2: pEpkey.asc --] [-- Type: application/pgp-keys, Size: 1763 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 4/N] Change timevar memory allocation to MiB. 2020-09-01 12:31 [PATCH 1/3] Support new mallinfo2 function Martin Liška 2020-09-01 12:32 ` [PATCH 2/3] Use MiB unit when displaying memory allocation Martin Liška 2020-09-01 12:33 ` [PATCH 3/3] Use more ONE_? in GGC functions Martin Liška @ 2020-09-01 13:38 ` Martin Liška 2020-09-02 13:29 ` Martin Liška 2020-09-02 13:28 ` [PATCH 1/3] Support new mallinfo2 function Martin Liška 3 siblings, 1 reply; 16+ messages in thread From: Martin Liška @ 2020-09-01 13:38 UTC (permalink / raw) To: GCC Patches; +Cc: Jan Hubicka [-- Attachment #1: Type: text/plain, Size: 2654 bytes --] And there's one more piece needed for -ftime-report: Time variable usr sys wall GGC phase setup : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 1%) 2 MiB ( 6%) phase opt and generate : 0.25 ( 40%) 0.02 ( 25%) 0.26 ( 37%) 0 MiB ( 1%) phase stream in : 0.18 ( 29%) 0.02 ( 25%) 0.20 ( 29%) 30 MiB ( 93%) phase stream out : 0.19 ( 31%) 0.04 ( 50%) 0.23 ( 33%) 0 MiB ( 0%) garbage collection : 0.03 ( 5%) 0.00 ( 0%) 0.03 ( 4%) 0 MiB ( 0%) callgraph optimization : 0.00 ( 0%) 0.00 ( 0%) 0.02 ( 3%) 0 MiB ( 0%) ipa ODR types : 0.00 ( 0%) 0.01 ( 12%) 0.00 ( 0%) 0 MiB ( 0%) ipa function summary : 0.01 ( 2%) 0.00 ( 0%) 0.00 ( 0%) 2 MiB ( 8%) ipa dead code removal : 0.03 ( 5%) 0.00 ( 0%) 0.03 ( 4%) 0 MiB ( 0%) ipa cp : 0.01 ( 2%) 0.00 ( 0%) 0.01 ( 1%) 0 MiB ( 0%) ipa inlining heuristics : 0.01 ( 2%) 0.00 ( 0%) 0.01 ( 1%) 0 MiB ( 0%) lto stream decompression : 0.01 ( 2%) 0.00 ( 0%) 0.00 ( 0%) 0 MiB ( 0%) ipa lto gimple out : 0.06 ( 10%) 0.01 ( 13%) 0.07 ( 10%) 0 MiB ( 0%) ipa lto decl in : 0.07 ( 11%) 0.01 ( 12%) 0.08 ( 11%) 18 MiB ( 57%) ipa lto decl out : 0.12 ( 19%) 0.00 ( 0%) 0.12 ( 17%) 0 MiB ( 0%) ipa lto cgraph I/O : 0.01 ( 2%) 0.00 ( 0%) 0.01 ( 1%) 8 MiB ( 27%) ipa lto decl merge : 0.04 ( 6%) 0.00 ( 0%) 0.04 ( 6%) 0 MiB ( 2%) whopr wpa I/O : 0.01 ( 2%) 0.03 ( 38%) 0.04 ( 6%) 0 MiB ( 0%) whopr partitioning : 0.04 ( 6%) 0.00 ( 0%) 0.04 ( 6%) 0 MiB ( 1%) ipa reference : 0.01 ( 2%) 0.00 ( 0%) 0.01 ( 1%) 0 MiB ( 0%) ipa profile : 0.01 ( 2%) 0.00 ( 0%) 0.01 ( 1%) 0 MiB ( 0%) ipa pure const : 0.01 ( 2%) 0.00 ( 0%) 0.01 ( 1%) 0 MiB ( 0%) ipa SRA : 0.01 ( 2%) 0.00 ( 0%) 0.01 ( 1%) 0 MiB ( 0%) callgraph verifier : 0.12 ( 19%) 0.02 ( 25%) 0.14 ( 20%) 0 MiB ( 0%) TOTAL : 0.62 0.08 0.70 32 MiB Martin [-- Attachment #2: 0001-Change-timevar-memory-allocation-to-MiB.patch --] [-- Type: text/x-patch, Size: 2668 bytes --] From e177610161e8ec22fee70bb2339195b5104bd30e Mon Sep 17 00:00:00 2001 From: Martin Liska <mliska@suse.cz> Date: Tue, 1 Sep 2020 14:44:40 +0200 Subject: [PATCH] Change timevar memory allocation to MiB. gcc/ChangeLog: * timevar.c (timer::print): Print memory allocation in MiB. gcc/testsuite/ChangeLog: * g++.dg/ext/timevar1.C: Expect values in MiB. * g++.dg/ext/timevar2.C: Likewise. --- gcc/testsuite/g++.dg/ext/timevar1.C | 2 +- gcc/testsuite/g++.dg/ext/timevar2.C | 2 +- gcc/timevar.c | 8 ++++---- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/gcc/testsuite/g++.dg/ext/timevar1.C b/gcc/testsuite/g++.dg/ext/timevar1.C index 3f891a50aba..d810ebe3451 100644 --- a/gcc/testsuite/g++.dg/ext/timevar1.C +++ b/gcc/testsuite/g++.dg/ext/timevar1.C @@ -2,7 +2,7 @@ // { dg-options "-ftime-report" } // { dg-allow-blank-lines-in-output 1 } // { dg-prune-output "Time variable" } -// { dg-prune-output " kB" } +// { dg-prune-output " MiB" } // { dg-prune-output "checks" } void diff --git a/gcc/testsuite/g++.dg/ext/timevar2.C b/gcc/testsuite/g++.dg/ext/timevar2.C index dd96d45c01e..fa68aac7e72 100644 --- a/gcc/testsuite/g++.dg/ext/timevar2.C +++ b/gcc/testsuite/g++.dg/ext/timevar2.C @@ -1,7 +1,7 @@ // PR c++/57524 // { dg-options "-ftime-report" } // { dg-prune-output "Time variable" } -// { dg-prune-output " kB" } +// { dg-prune-output " MiB" } // { dg-prune-output "checks" } namespace detail { diff --git a/gcc/timevar.c b/gcc/timevar.c index a3a882d3204..43b17571da2 100644 --- a/gcc/timevar.c +++ b/gcc/timevar.c @@ -661,8 +661,8 @@ timer::print_row (FILE *fp, #endif /* HAVE_WALL_TIME */ /* Print the amount of ggc memory allocated. */ - fprintf (fp, "%8u kB (%3.0f%%)", - (unsigned) (elapsed.ggc_mem >> 10), + fprintf (fp, "%8u MiB (%3.0f%%)", + (unsigned ) (elapsed.ggc_mem / ONE_M), (total->ggc_mem == 0 ? 0 : (float) elapsed.ggc_mem / total->ggc_mem) * 100); @@ -712,7 +712,7 @@ timer::print (FILE *fp) TIMEVAR. */ m_start_time = now; - fprintf (fp, "\n%-35s%16s%14s%14s%18s\n", "Time variable", "usr", "sys", + fprintf (fp, "\n%-35s%16s%14s%14s%19s\n", "Time variable", "usr", "sys", "wall", "GGC"); if (m_jit_client_items) fputs ("GCC items:\n", fp); @@ -776,7 +776,7 @@ timer::print (FILE *fp) #ifdef HAVE_WALL_TIME fprintf (fp, "%8.2f ", total->wall); #endif - fprintf (fp, "%9u kB\n", (unsigned) (total->ggc_mem >> 10)); + fprintf (fp, "%9u MiB\n", (unsigned) (total->ggc_mem / ONE_M)); if (CHECKING_P || flag_checking) fprintf (fp, "Extra diagnostic checks enabled; compiler may run slowly.\n"); -- 2.28.0 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 4/N] Change timevar memory allocation to MiB. 2020-09-01 13:38 ` [PATCH 4/N] Change timevar memory allocation to MiB Martin Liška @ 2020-09-02 13:29 ` Martin Liška 0 siblings, 0 replies; 16+ messages in thread From: Martin Liška @ 2020-09-02 13:29 UTC (permalink / raw) To: GCC Patches; +Cc: Jan Hubicka Please forget about the patch. It's part of 02/N v2. Martin ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] Support new mallinfo2 function. 2020-09-01 12:31 [PATCH 1/3] Support new mallinfo2 function Martin Liška ` (2 preceding siblings ...) 2020-09-01 13:38 ` [PATCH 4/N] Change timevar memory allocation to MiB Martin Liška @ 2020-09-02 13:28 ` Martin Liška 2020-09-17 21:56 ` Jeff Law 3 siblings, 1 reply; 16+ messages in thread From: Martin Liška @ 2020-09-02 13:28 UTC (permalink / raw) To: GCC Patches; +Cc: Jan Hubicka [-- Attachment #1: Type: text/plain, Size: 458 bytes --] On 9/1/20 2:31 PM, Martin Liška wrote: > Hey. > > I've just applied to patches to glibc introducing a new mallinfo2 function. > Limitation of the current function mallinfo is usage of int type which overflows > for allocation > 2GB. > > The patch adds configure detection and usage of the new one. And it prints heap usage > in MiB. > > Ready to be installed after tests? > Thanks, > Martin All right, there's V2 where I just support mallinfo2. Martin [-- Attachment #2: 0001-Support-new-mallinfo2-function.patch --] [-- Type: text/x-patch, Size: 4671 bytes --] From bdb6dcf8fbd51a9dc62e6a50a7eeedc734c130f9 Mon Sep 17 00:00:00 2001 From: Martin Liska <mliska@suse.cz> Date: Tue, 1 Sep 2020 14:14:45 +0200 Subject: [PATCH 1/3] Support new mallinfo2 function. gcc/ChangeLog: * config.in: Regenerate. * configure: Likewise. * configure.ac: Detect for mallinfo2. * ggc-common.c (defined): Use it. * system.h: Handle also HAVE_MALLINFO2. --- gcc/config.in | 16 ++++++++++++++-- gcc/configure | 4 ++-- gcc/configure.ac | 4 ++-- gcc/ggc-common.c | 12 +++++++++--- gcc/system.h | 2 +- 5 files changed, 28 insertions(+), 10 deletions(-) diff --git a/gcc/config.in b/gcc/config.in index 478e74fac02..1832c112ed9 100644 --- a/gcc/config.in +++ b/gcc/config.in @@ -983,13 +983,19 @@ #endif -/* Define to 1 if we found a declaration for 'mallinfo', otherwise define to - 0. */ +/* Define to 1 if we found a declaration for 'mallinfo */ #ifndef USED_FOR_TARGET #undef HAVE_DECL_MALLINFO #endif +/* Define to 1 if we found a declaration for 'mallinfo2', otherwise define to + 0. */ +#ifndef USED_FOR_TARGET +#undef HAVE_DECL_MALLINFO2 +#endif + + /* Define to 1 if we found a declaration for 'malloc', otherwise define to 0. */ #ifndef USED_FOR_TARGET @@ -1665,6 +1671,12 @@ #endif +/* Define to 1 if you have the `mallinfo2' function. */ +#ifndef USED_FOR_TARGET +#undef HAVE_MALLINFO2 +#endif + + /* Define to 1 if you have the <malloc.h> header file. */ #ifndef USED_FOR_TARGET #undef HAVE_MALLOC_H diff --git a/gcc/configure b/gcc/configure index 0f7a8dbe0f9..b8b9bd3505b 100755 --- a/gcc/configure +++ b/gcc/configure @@ -10120,7 +10120,7 @@ fi for ac_func in times clock kill getrlimit setrlimit atoq \ popen sysconf strsignal getrusage nl_langinfo \ gettimeofday mbstowcs wcswidth mmap setlocale \ - clearerr_unlocked feof_unlocked ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked putchar_unlocked putc_unlocked madvise mallinfo + clearerr_unlocked feof_unlocked ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked putchar_unlocked putc_unlocked madvise mallinfo mallinfo2 do : as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh` ac_fn_cxx_check_func "$LINENO" "$ac_func" "$as_ac_var" @@ -11549,7 +11549,7 @@ fi done -for ac_func in mallinfo +for ac_func in mallinfo, mallinfo2 do ac_tr_decl=`$as_echo "HAVE_DECL_$ac_func" | $as_tr_cpp` { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $ac_func is declared" >&5 diff --git a/gcc/configure.ac b/gcc/configure.ac index 0f11238c19f..18640fdb8a5 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -1408,7 +1408,7 @@ define(gcc_UNLOCKED_FUNCS, clearerr_unlocked feof_unlocked dnl AC_CHECK_FUNCS(times clock kill getrlimit setrlimit atoq \ popen sysconf strsignal getrusage nl_langinfo \ gettimeofday mbstowcs wcswidth mmap setlocale \ - gcc_UNLOCKED_FUNCS madvise mallinfo) + gcc_UNLOCKED_FUNCS madvise mallinfo mallinfo2) if test x$ac_cv_func_mbstowcs = xyes; then AC_CACHE_CHECK(whether mbstowcs works, gcc_cv_func_mbstowcs_works, @@ -1488,7 +1488,7 @@ gcc_AC_CHECK_DECLS(getrlimit setrlimit getrusage, , ,[ #endif ]) -gcc_AC_CHECK_DECLS(mallinfo, , ,[ +gcc_AC_CHECK_DECLS([mallinfo, mallinfo2], , ,[ #include "ansidecl.h" #include "system.h" #ifdef HAVE_MALLOC_H diff --git a/gcc/ggc-common.c b/gcc/ggc-common.c index 94da02f1185..b8782c5824b 100644 --- a/gcc/ggc-common.c +++ b/gcc/ggc-common.c @@ -1008,13 +1008,19 @@ ggc_prune_overhead_list (void) } } -/* Return memory used by heap in kb, 0 if this info is not available. */ +/* Print memory used by heap in kb if this info is not available. */ void report_heap_memory_use () { -#ifdef HAVE_MALLINFO +#if defined(HAVE_MALLINFO) || defined(HAVE_MALLINFO2) +#ifdef HAVE_MALLINFO2 + #define MALLINFO_FN mallinfo2 +#else + #define MALLINFO_FN mallinfo +#endif if (!quiet_flag) - fprintf (stderr," {heap %luk}", (unsigned long)(mallinfo().arena / 1024)); + fprintf (stderr," {heap %luk}", + (unsigned long) MALLINFO_FN ().arena / ONE_K); #endif } diff --git a/gcc/system.h b/gcc/system.h index 3c543a005d8..4f0482be25d 100644 --- a/gcc/system.h +++ b/gcc/system.h @@ -732,7 +732,7 @@ extern int vsnprintf (char *, size_t, const char *, va_list); #endif #ifdef INCLUDE_MALLOC_H -#ifdef HAVE_MALLINFO +#if defined(HAVE_MALLINFO) || defined(HAVE_MALLINFO2) #include <malloc.h> #endif #endif -- 2.28.0 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] Support new mallinfo2 function. 2020-09-02 13:28 ` [PATCH 1/3] Support new mallinfo2 function Martin Liška @ 2020-09-17 21:56 ` Jeff Law 0 siblings, 0 replies; 16+ messages in thread From: Jeff Law @ 2020-09-17 21:56 UTC (permalink / raw) To: Martin Liška, GCC Patches; +Cc: Jan Hubicka [-- Attachment #1: Type: text/plain, Size: 4899 bytes --] On 9/2/20 7:28 AM, Martin Liška wrote: > On 9/1/20 2:31 PM, Martin Liška wrote: >> Hey. >> >> I've just applied to patches to glibc introducing a new mallinfo2 >> function. >> Limitation of the current function mallinfo is usage of int type >> which overflows >> for allocation > 2GB. >> >> The patch adds configure detection and usage of the new one. And it >> prints heap usage >> in MiB. >> >> Ready to be installed after tests? >> Thanks, >> Martin > > All right, there's V2 where I just support mallinfo2. > > Martin > > 0001-Support-new-mallinfo2-function.patch > > From bdb6dcf8fbd51a9dc62e6a50a7eeedc734c130f9 Mon Sep 17 00:00:00 2001 > From: Martin Liska <mliska@suse.cz> > Date: Tue, 1 Sep 2020 14:14:45 +0200 > Subject: [PATCH 1/3] Support new mallinfo2 function. > > gcc/ChangeLog: > > * config.in: Regenerate. > * configure: Likewise. > * configure.ac: Detect for mallinfo2. > * ggc-common.c (defined): Use it. > * system.h: Handle also HAVE_MALLINFO2. > --- > gcc/config.in | 16 ++++++++++++++-- > gcc/configure | 4 ++-- > gcc/configure.ac | 4 ++-- > gcc/ggc-common.c | 12 +++++++++--- > gcc/system.h | 2 +- > 5 files changed, 28 insertions(+), 10 deletions(-) > > diff --git a/gcc/config.in b/gcc/config.in > index 478e74fac02..1832c112ed9 100644 > --- a/gcc/config.in > +++ b/gcc/config.in > @@ -983,13 +983,19 @@ > #endif > > > -/* Define to 1 if we found a declaration for 'mallinfo', otherwise define to > - 0. */ > +/* Define to 1 if we found a declaration for 'mallinfo */ > #ifndef USED_FOR_TARGET > #undef HAVE_DECL_MALLINFO > #endif > > > +/* Define to 1 if we found a declaration for 'mallinfo2', otherwise define to > + 0. */ > +#ifndef USED_FOR_TARGET > +#undef HAVE_DECL_MALLINFO2 > +#endif > + > + > /* Define to 1 if we found a declaration for 'malloc', otherwise define to 0. > */ > #ifndef USED_FOR_TARGET > @@ -1665,6 +1671,12 @@ > #endif > > > +/* Define to 1 if you have the `mallinfo2' function. */ > +#ifndef USED_FOR_TARGET > +#undef HAVE_MALLINFO2 > +#endif > + > + > /* Define to 1 if you have the <malloc.h> header file. */ > #ifndef USED_FOR_TARGET > #undef HAVE_MALLOC_H > diff --git a/gcc/configure b/gcc/configure > index 0f7a8dbe0f9..b8b9bd3505b 100755 > --- a/gcc/configure > +++ b/gcc/configure > @@ -10120,7 +10120,7 @@ fi > for ac_func in times clock kill getrlimit setrlimit atoq \ > popen sysconf strsignal getrusage nl_langinfo \ > gettimeofday mbstowcs wcswidth mmap setlocale \ > - clearerr_unlocked feof_unlocked ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked putchar_unlocked putc_unlocked madvise mallinfo > + clearerr_unlocked feof_unlocked ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked putchar_unlocked putc_unlocked madvise mallinfo mallinfo2 > do : > as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh` > ac_fn_cxx_check_func "$LINENO" "$ac_func" "$as_ac_var" > @@ -11549,7 +11549,7 @@ fi > done > > > -for ac_func in mallinfo > +for ac_func in mallinfo, mallinfo2 > do > ac_tr_decl=`$as_echo "HAVE_DECL_$ac_func" | $as_tr_cpp` > { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $ac_func is declared" >&5 > diff --git a/gcc/configure.ac b/gcc/configure.ac > index 0f11238c19f..18640fdb8a5 100644 > --- a/gcc/configure.ac > +++ b/gcc/configure.ac > @@ -1408,7 +1408,7 @@ define(gcc_UNLOCKED_FUNCS, clearerr_unlocked feof_unlocked dnl > AC_CHECK_FUNCS(times clock kill getrlimit setrlimit atoq \ > popen sysconf strsignal getrusage nl_langinfo \ > gettimeofday mbstowcs wcswidth mmap setlocale \ > - gcc_UNLOCKED_FUNCS madvise mallinfo) > + gcc_UNLOCKED_FUNCS madvise mallinfo mallinfo2) > > if test x$ac_cv_func_mbstowcs = xyes; then > AC_CACHE_CHECK(whether mbstowcs works, gcc_cv_func_mbstowcs_works, > @@ -1488,7 +1488,7 @@ gcc_AC_CHECK_DECLS(getrlimit setrlimit getrusage, , ,[ > #endif > ]) > > -gcc_AC_CHECK_DECLS(mallinfo, , ,[ > +gcc_AC_CHECK_DECLS([mallinfo, mallinfo2], , ,[ > #include "ansidecl.h" > #include "system.h" > #ifdef HAVE_MALLOC_H > diff --git a/gcc/ggc-common.c b/gcc/ggc-common.c > index 94da02f1185..b8782c5824b 100644 > --- a/gcc/ggc-common.c > +++ b/gcc/ggc-common.c > @@ -1008,13 +1008,19 @@ ggc_prune_overhead_list (void) > } > } > > -/* Return memory used by heap in kb, 0 if this info is not available. */ > +/* Print memory used by heap in kb if this info is not available. */ This comment seems wrong... OK with the comment fixed. jeff [-- Attachment #2: pEpkey.asc --] [-- Type: application/pgp-keys, Size: 1763 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2020-09-22 13:24 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-09-01 12:31 [PATCH 1/3] Support new mallinfo2 function Martin Liška 2020-09-01 12:32 ` [PATCH 2/3] Use MiB unit when displaying memory allocation Martin Liška 2020-09-01 14:04 ` Jan Hubicka 2020-09-02 13:28 ` Martin Liška 2020-09-17 21:57 ` Jeff Law 2020-09-22 7:47 ` Christophe Lyon 2020-09-22 8:30 ` Martin Liška 2020-09-22 13:02 ` Marek Polacek 2020-09-22 13:24 ` Marek Polacek 2020-09-01 12:33 ` [PATCH 3/3] Use more ONE_? in GGC functions Martin Liška 2020-09-02 13:29 ` Martin Liška 2020-09-17 21:57 ` Jeff Law 2020-09-01 13:38 ` [PATCH 4/N] Change timevar memory allocation to MiB Martin Liška 2020-09-02 13:29 ` Martin Liška 2020-09-02 13:28 ` [PATCH 1/3] Support new mallinfo2 function Martin Liška 2020-09-17 21:56 ` Jeff Law
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).