Re: [gold][patch] Cleanup more mmap leakage

[Cary Coutant <ccoutant at google dot com>]

Ping...

On Fri, Mar 26, 2010 at 4:13 PM, Cary Coutant <ccoutant@google.com> wrote:
> This patch fixes some more mmap leakage that I've found in processing
> thin archives, shared libraries, and during garbage collection. As far
> as I can tell now, --no-keep-files-mapped now releases all the memory
> it should between passes. These fixes reduce gold's maximum memory
> usage slightly, but didn't make any significant performance difference
> on the tests I ran.
>
> In most cases, gold is careful to explicitly delete File_view objects
> as soon as they are no longer needed, but there were unusual code
> paths (e.g., when a shared library is added a second time) that were
> missing those explicit delete statements. I chose to add destructors
> to make sure that all File_view members are deleted when
> Read_symbols_data and Read_relocs_data objects are destroyed, and to
> make sure that the Read_symbols_data and Read_relocs_data objects are
> destroyed before releasing the associated file (so that
> File_read::clear_views would unmap the regions). I didn't bother to
> remove the places where the File_view objects were explicitly deleted,
> since in those places it's still better to delete them as early as
> possible.
>
> No regressions on x86_64. OK to checkin?
>
> -cary
>
> ? ? ? ?* archive.cc (include_member): Destroy Read_symbols_data object before
> ? ? ? ?releasing file.
> ? ? ? ?* object.cc (Read_symbols_data::~Read_symbols_data) New destructor.
> ? ? ? ?* object.h (Read_symbols_data::Read_symbols_data) New constructor.
> ? ? ? ?(Read_symbols_data::~Read_symbols_data) New destructor.
> ? ? ? ?(Section_relocs::Section_relocs) New constructor.
> ? ? ? ?(Section_relocs::~Section_relocs) New destructor.
> ? ? ? ?(Read_relocs_data::Read_relocs_data) New constructor.
> ? ? ? ?(Read_relocs_data::~Read_relocs_data) New destructor.
> ? ? ? ?* testsuite/binary_unittest.cc (Sized_binary_test): Set sd member
> ? ? ? ?pointers to NULL after deleting.
>