In the spirit of other changes over the past month aimed at supporting

monster-sized programs better, increase the default freelist volume
from 1M to 5M.  Maybe even that is too small.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4954
This commit is contained in:
Julian Seward 2005-10-20 00:31:31 +00:00
parent 1a90cce793
commit 5be669c562
3 changed files with 4 additions and 4 deletions

View File

@ -308,7 +308,7 @@ from tool-vs-core version incompatibilities.
.TP
.B
--freelist-vol=<number> [default: 1000000]
--freelist-vol=<number> [default: 5000000]
When the client program releases memory using free (in C) or delete
(C++), that memory is not immediately made available for re-allocation.
Instead it is marked inaccessible and placed in a queue of freed blocks.

View File

@ -120,7 +120,7 @@ Memcheck can detect the following problems:</para>
<listitem id="freelist">
<para><computeroutput>--freelist-vol=&lt;number></computeroutput>
[default: 1000000]</para>
[default: 5000000]</para>
<para>When the client program releases memory using free (in
<literal>C</literal>) or delete (<literal>C++</literal>),
that memory is not immediately made available for

View File

@ -59,7 +59,7 @@
/*------------------------------------------------------------*/
Bool MAC_(clo_partial_loads_ok) = True;
Int MAC_(clo_freelist_vol) = 1000000;
Int MAC_(clo_freelist_vol) = 5000000;
LeakCheckMode MAC_(clo_leak_check) = LC_Summary;
VgRes MAC_(clo_leak_resolution) = Vg_LowRes;
Bool MAC_(clo_show_reachable) = False;
@ -101,7 +101,7 @@ void MAC_(print_common_usage)(void)
" --leak-resolution=low|med|high how much bt merging in leak check [low]\n"
" --show-reachable=no|yes show reachable blocks in leak check? [no]\n"
" --partial-loads-ok=no|yes too hard to explain here; see manual [yes]\n"
" --freelist-vol=<number> volume of freed blocks queue [1000000]\n"
" --freelist-vol=<number> volume of freed blocks queue [5000000]\n"
" --workaround-gcc296-bugs=no|yes self explanatory [no]\n"
);
VG_(replacement_malloc_print_usage)();