diff options
| author | Kostya Kortchinsky <kostyak@google.com> | 2018-09-19 19:50:35 +0000 |
|---|---|---|
| committer | Kostya Kortchinsky <kostyak@google.com> | 2018-09-19 19:50:35 +0000 |
| commit | 851a7c9b2b9e4f273f968885bd1df88fcca92d59 (patch) | |
| tree | 390322d31367f44efe10d489daaf24b5ea042e3d /llvm/lib/CodeGen/MachineScheduler.cpp | |
| parent | c62ab611732099180ae3e5d3774ed43747b40051 (diff) | |
| download | llvm-851a7c9b2b9e4f273f968885bd1df88fcca92d59.zip llvm-851a7c9b2b9e4f273f968885bd1df88fcca92d59.tar.gz llvm-851a7c9b2b9e4f273f968885bd1df88fcca92d59.tar.bz2 | |
[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
Diffstat (limited to 'llvm/lib/CodeGen/MachineScheduler.cpp')
0 files changed, 0 insertions, 0 deletions