Re: [RFC 2/2] [gdb/exp] Clean up asap in value_print_array_elements

[Tom Tromey <tom@tromey.com>]

>>>>> "Tom" == Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> writes:

Tom> I've been running the test-suite on an i686-linux laptop with 1GB of memory,
Tom> and 1 GB of swap, and noticed problems after running gdb.base/huge.exp: gdb
Tom> not being able to spawn for a large number of test-cases afterwards.

Tom> So I investigated the memory usage, on my usual x86_64-linux development
Tom> platform.

Thank you for doing this.

Tom> The problem also exists for Ada:
Tom> ...
Tom> +print Arr
Tom> value_free_to_mark freed 2097152 items
Tom> $1 = (0 <repeats 2097152 times>)
Tom> ...
Tom> but is fixed by the fix for C.

I suspect a similar problem exists in val_print_packed_array_elements,
which is only used for packed arrays.  I am happy to fix this up after
your patch goes in, though.

Tom> RFC: the regression test included in the patch is formulated in its weakest
Tom> form, to avoid false positive FAILs, which also means that smaller regressions
Tom> may not get detected.

Tom> A better way to write a regression test could involve adding more specific or
Tom> complete memory statistics, for instance:
Tom> - use the equivalent of VIRT as displayed by top, in a command
Tom>   "maint set per-command virt-space on/off", or
Tom> - use gdb-specific memory statistics, printed by
Tom>   "maint set per-command mem-stats on/off", with one line containing
Tom>   "max value_free_to_mark freed items: <n>".

Tom> The latter has less generic usefullness, but is easier to implement and easy
Tom> to extend, and can be written such that it's guaranteed to work the same on
Tom> all platforms, so it's my preferred option.

Tom> Alternatively, we could add a warning in value_free_to_mark with a treshold
Tom> controlled by a setting.

I tend to think what you did here is fine.  The main point is to avoid
explosive growth.

Approved-By: Tom Tromey <tom@tromey.com>

Tom