[PATCH] D52242: [sanitizer] Destroy and close a range's vmar if all its memory was unmapped

Kostya Kortchinsky via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Sep 18 11:51:21 PDT 2018


cryptoad created this revision.
cryptoad added reviewers: flowerhack, mcgrathr, phosek, mseaborn.
Herald added subscribers: Sanitizers, delcypher, kubamracek.

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.


Repository:
  rCRT Compiler Runtime

https://reviews.llvm.org/D52242

Files:
  lib/sanitizer_common/sanitizer_fuchsia.cc


Index: lib/sanitizer_common/sanitizer_fuchsia.cc
===================================================================
--- lib/sanitizer_common/sanitizer_fuchsia.cc
+++ lib/sanitizer_common/sanitizer_fuchsia.cc
@@ -283,8 +283,14 @@
   else
     CHECK_EQ(addr + size, reinterpret_cast<uptr>(base_) + size_);
   size_ -= size;
-  UnmapOrDieVmar(reinterpret_cast<void *>(addr), size,
-                 static_cast<zx_handle_t>(os_handle_));
+  const zx_handle_t vmar = static_cast<zx_handle_t>(os_handle_);
+  UnmapOrDieVmar(reinterpret_cast<void *>(addr), size, vmar);
+  if (!base_) {
+    // If we unmapped the whole range, destroy and close the vmar.
+    _zx_vmar_destroy(vmar);
+    _zx_handle_close(vmar);
+    os_handle_ = static_cast<uptr>(ZX_HANDLE_INVALID);
+  }
 }
 
 // This should never be called.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D52242.166013.patch
Type: text/x-patch
Size: 807 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180918/508a4d07/attachment.bin>


More information about the llvm-commits mailing list