[sanitizer][fuchsia] Fix VMAR leak
authorKostya Kortchinsky <kostyak@google.com>
Wed, 19 Sep 2018 19:50:35 +0000 (19:50 +0000)
committerKostya Kortchinsky <kostyak@google.com>
Wed, 19 Sep 2018 19:50:35 +0000 (19:50 +0000)
commit851a7c9b2b9e4f273f968885bd1df88fcca92d59
tree390322d31367f44efe10d489daaf24b5ea042e3d
parentc62ab611732099180ae3e5d3774ed43747b40051
[sanitizer][fuchsia] Fix VMAR leak

Summary:
Destroy and close a range's vmar if all its memory was unmapped.

This addresses some performance regression due to the proliferation of vmars
when Secondary backed allocations are concerned with Scudo on Fuchsia.

When a Secondary backed allocation was freed, the associated
`ReservedAddressRange` was going away after unmapping the entirety of the
mapping, but without getting rid of the associated vmar properly (which
was created specifically for that mapping). This resulted in an increase of
defunct vmars, that in turn slowed down further new vmar allocations.

This appears to solve ZX-2560/ZX-2642, at least on QEMU.

Reviewers: flowerhack, mcgrathr, phosek, mseaborn

Reviewed By: mcgrathr

Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits

Differential Revision: https://reviews.llvm.org/D52242

llvm-svn: 342584
compiler-rt/lib/sanitizer_common/sanitizer_fuchsia.cc