llvm dev - Jul 2017 - [compiler-rt] Proposed changes to MemoryMappingLayout (sanitizer_procmaps)

Hi all,

LeakSanitizer on Darwin has some performance issues caused by scanning
unnecessary sections in the MachO __DATA segment (things like
objective-c metadata, strings, selectors, etc). Based on the relative
sizes of these sections and profiling data for moderately-sized
Objective-C programs, I estimate that performance would be improved by
70-80% by only scanning __data, __bss, and __common MachO sections for
pointers instead of the entire __DATA segment.

In order to reveal section information using MemoryMappingLayout, I
would like to make a few changes:

1) Move from MemoryMappingLayout::Next() to c++ style iterators
2) Introduce a new class MemoryMappedSegment, which is returned by
MemoryMappingLayout iterators
3) Introduce a new class MemoryMappedSection, which is returned by
MemoryMappedSegment iterators

On ELF targets, each MemoryMappedSegment would contain a single
MemoryMappedSection, which would be the ELF section currently returned
by MemoryMappingLayout::Next(), maintaining current behavior.

On MachO targets, a MemoryMappedSection would correspond to a MachO
section, revealing the necessary section data to LeakSanitizer.

The address ranges in each module returned by
MemoryMappingLayout::DumpListOfModules() would be unchanged on ELF
targets, but would correspond to a MachO section instead of a MachO
segment on MachO targets.

This is a somewhat large and invasive change that will affect
sanitizers beyond just LeakSanitizer, so I'm very open to input about
the design before I write up the implementation.

Francis

On Wed, Jul 5, 2017 at 5:27 PM, Francis Ricci <francisjricci at gmail.com>
wrote:
> Hi all,
>
> LeakSanitizer on Darwin has some performance issues caused by scanning
> unnecessary sections in the MachO __DATA segment (things like
> objective-c metadata, strings, selectors, etc). Based on the relative
> sizes of these sections and profiling data for moderately-sized
> Objective-C programs, I estimate that performance would be improved by
> 70-80% by only scanning __data, __bss, and __common MachO sections for
> pointers instead of the entire __DATA segment.
>
> In order to reveal section information using MemoryMappingLayout, I
> would like to make a few changes:
>
> 1) Move from MemoryMappingLayout::Next() to c++ style iterators
> 2) Introduce a new class MemoryMappedSegment, which is returned by
> MemoryMappingLayout iterators
> 3) Introduce a new class MemoryMappedSection, which is returned by
> MemoryMappedSegment iterators
>
> On ELF targets, each MemoryMappedSegment would contain a single
> MemoryMappedSection, which would be the ELF section currently returned
> by MemoryMappingLayout::Next(), maintaining current behavior.
>
> On MachO targets, a MemoryMappedSection would correspond to a MachO
> section, revealing the necessary section data to LeakSanitizer.
>
> The address ranges in each module returned by
> MemoryMappingLayout::DumpListOfModules() would be unchanged on ELF
> targets, but would correspond to a MachO section instead of a MachO
> segment on MachO targets.
>
> This is a somewhat large and invasive change that will affect
> sanitizers beyond just LeakSanitizer, so I'm very open to input about
> the design before I write up the implementation.

Hi Francis,

Generally sounds fine to me.

You will need to separate refactoring (collecting all attributes into
a struct, switching to iterators, etc) from actual code changes.

Also, it may be simpler if  you flatten segments/sections into just
sections and pull necessary segment attributes into section.

On Wed, Jul 5, 2017 at 8:27 AM, Francis Ricci via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
> 1) Move from MemoryMappingLayout::Next() to c++ style iterators

I would hesitate to do that, given the diverse ways that address space
introspection can fail. Currently these are all CHECK failures on BSD &
Linux and an early exit on Mac. You might want an interface capable of
returning an error.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170706/76ff00ef/attachment.html>