Thanks a lot for all these replies! They really help me understand the
design.
When I measured performance of sanitizer allocator against tcmalloc on
a large real application that calls malloc a lot, sanitizer allocator
was 10% faster.
This is interesting! It probably means there are no large
On Fri, Sep 26, 2014 at 12:29 PM, Jonas Wagner jonas.wag...@epfl.ch wrote:
Thanks a lot for all these replies! They really help me understand the
design.
When I measured performance of sanitizer allocator against tcmalloc on
a large real application that calls malloc a lot, sanitizer
Hi,
Compared to other SPEC benchmarks, the fraction of overhead due to checks
is
very low for gcc. Much overhead seems to come from heap poisoning and
from
the quarantine queue, but there are also some 30% of overhead that hide
elsewhere… I suspect that the allocator might be to blame.
On Fri, Sep 26, 2014 at 1:29 AM, Jonas Wagner jonas.wag...@epfl.ch wrote:
Thanks a lot for all these replies! They really help me understand the
design.
When I measured performance of sanitizer allocator against tcmalloc on
a large real application that calls malloc a lot, sanitizer allocator
On Fri, Sep 26, 2014 at 4:08 PM, Jonas Wagner jonas.wag...@epfl.ch wrote:
Also, this might be very interesting for the stack, too. I think even a
slightly randomized stack layout (through random redzone sizes or variable
reordering) could make it harder to write exploits. I know ASan is a
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
On Thu, Sep 25, 2014 at 8:49 AM, 'Dmitry Vyukov' via address-sanitizer
address-sanitizer@googlegroups.com wrote:
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.
