This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: PATCH: fail to improve psymtab memory consumption
- To: Jim Blandy <jimb at zwingli dot cygnus dot com>
- Subject: Re: PATCH: fail to improve psymtab memory consumption
- From: Daniel Berlin <dan at cgsoftware dot com>
- Date: Fri, 20 Jul 2001 18:17:19 -0400
- Cc: gdb-patches at sources dot redhat dot com
- References: <20010720212013.7DA695E9D8@zwingli.cygnus.com>
Jim Blandy <jimb@zwingli.cygnus.com> writes:
> As Daniel said...
>
> 2001-07-20 Jim Blandy <jimb@redhat.com>
>
> * dwarf2read.c (dwarf2_build_psymtabs_hard): Doc fix.
>
> Index: gdb/dwarf2read.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/dwarf2read.c,v
> retrieving revision 1.29
> diff -c -r1.29 dwarf2read.c
> *** gdb/dwarf2read.c 2001/07/05 16:45:48 1.29
> --- gdb/dwarf2read.c 2001/07/20 21:15:51
> ***************
> *** 977,982 ****
> --- 977,1010 ----
> info_ptr = dwarf_info_buffer;
> abbrev_ptr = dwarf_abbrev_buffer;
>
>+ /* We use dwarf2_tmp_obstack for objects that don't need to survive
>+ the partial symbol scan, like attribute values.
>+
>+ We could reduce our peak memory consumption during partial symbol
>+ table construction by freeing stuff from this obstack more often
>+ --- say, after processing each compilation unit, or each die ---
>+ but it turns out that this saves almost nothing. For an
>+ executable with 11Mb of Dwarf 2 data, I found about 64k allocated
>+ on dwarf2_tmp_obstack. Some investigation showed:
>+
>+ 1) 69% of the attributes used forms DW_FORM_addr, DW_FORM_data*,
>+ DW_FORM_flag, DW_FORM_[su]data, and DW_FORM_ref*. These are
>+ all fixed-length values not requiring dynamic allocation.
>+
>+ 2) 30% of the attributes used the form DW_FORM_string. For
>+ DW_FORM_string, read_attribute simply hands back a pointer to
>+ the null-terminated string in dwarf_info_buffer, so no dynamic
>+ allocation is needed there either.
>+
>+ 3) The remaining 1% of the attributes all used DW_FORM_block1.
>+ 75% of those were DW_AT_frame_base location lists for
>+ functions; the rest were DW_AT_location attributes, probably
>+ for the global variables.
>+
>+ Anyway, what this all means is that the memory the dwarf2
>+ reader uses as temporary space reading partial symbols is about
>+ 0.5% as much as we use for dwarf_*_buffer. That's noise. */
>+
Hence the reason I only read the part of
the various sections for a given CU (rather than reading the entire
section). If you look at the new dwarf2 reader, you'll notice we jump
through a few hoops in some places to do this (IE we read a header,
then free it, just to get the size, etc).
I actually use mmap when possible, but that's for speed, rather than
memory savings.
It doesn't buy us anything if we still mmap the entire section, and
then touch every part. :)
--Dan
--
"I have a microwave fireplace in my house... The other night I
laid down in front of the fire for the evening in two minutes.
"-Steven Wright