Francis Ricci via llvm-dev
2017-Jul-05 15:27 UTC
[llvm-dev] [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
Dmitry Vyukov via llvm-dev
2017-Jul-05 15:55 UTC
[llvm-dev] [compiler-rt] Proposed changes to MemoryMappingLayout (sanitizer_procmaps)
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.
Reid Kleckner via llvm-dev
2017-Jul-06 18:32 UTC
[llvm-dev] [compiler-rt] Proposed changes to MemoryMappingLayout (sanitizer_procmaps)
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 iteratorsI 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>