On Thu, Sep 25, 2014 at 7:44 AM, Jonas Wagner <jonas.wag...@epfl.ch> wrote: > Dear AddressSanitizer developers, > > I'm thinking about ways to optimize the performance of ASan's allocator. > There are a few benchmarks where a large fraction of the overhead comes from > the allocator and the quarantine queue, rather than the checks themselves > (e.g., gcc from SPEC2006). > > When I looked at the allocator, I was surprised that it is implemented > inside ASan's runtime library (or rather, in sanitizer_common). This is > unlike other intercepted functions such as strcpy, which forward to the > implementation from libc. What is the reason for this? > > Would it be possible to implement asan_malloc as a decorator on top of libc > malloc? Or on top of an existing implementation such as tcmalloc? This seems > desirable to me because these are highly tuned. It might also simplify the > sanitizer codebase. > > I'm sure this case has been considered. What are the reasons for the current > design? > > Besides this question, I wonder if there are other ways of optimizing the > allocator or the quarantine mechanism. If you can think of any (relatively) > low-hanging fruit, I'd be motivated to give it a try.
Hi Jonas, When I measured performance of sanitizer allocator against tcmalloc on a large real application that calls malloc a lot, sanitizer allocator was 10% faster. You are free to do you own measurements. Maybe you will discover some inefficiency in the allocator that you can fix. One historical reason for using own allocator is that we needed the meta information that is not covered by shadow, so it can't be a simple prefix/postfix of the memory block itself. We don't use the meta info anymore. Even if we switch to tcmalloc, we still need quarantine on top of it. And quarantine kills cache locality. You remove that overhead simply by switching to a different allocator. One of the low hanging fruits is disabling allocator stats for asan. The stats are required for tsan, but asan keeps own stats. So it's possible to implement a NoOpStats class for asan, and parametrize the allocator with that class. I don't know of any other low hanging fruits. Also note that the allocator must scale well for high core counts. -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
