[llvm] [ORC] Add opt-in per-JITDylib colocating slab allocator (PR #207970)

Jared Wyles via llvm-commits llvm-commits at lists.llvm.org
Tue Jul 28 20:09:41 PDT 2026


================
@@ -54,9 +55,58 @@ class MapperJITLinkMemoryManager::InFlightAlloc
 };
 
 MapperJITLinkMemoryManager::MapperJITLinkMemoryManager(
-    size_t ReservationGranularity, std::unique_ptr<MemoryMapper> Mapper)
-    : ReservationUnits(ReservationGranularity), AvailableMemory(AMAllocator),
-      Mapper(std::move(Mapper)) {}
+    size_t ReservationGranularity, std::unique_ptr<MemoryMapper> Mapper,
+    bool ColocatePerJITDylib)
+    : ReservationUnits(ReservationGranularity),
+      ColocatePerJITDylib(ColocatePerJITDylib), Mapper(std::move(Mapper)) {}
+
+// Lazily creates and stores Key's pool on first access. Pools are
+// heap-allocated behind unique_ptr so the returned reference survives map
+// rehashing, and AMAllocator (declared before the pools) outlives them.
+MapperJITLinkMemoryManager::AvailableMemoryMap &
+MapperJITLinkMemoryManager::getAvailableMemory(const JITLinkDylib *Key) {
+  auto &Pool = AvailableMemoryPools[Key];
+  if (!Pool)
+    Pool = std::make_unique<AvailableMemoryMap>(AMAllocator);
+  return *Pool;
+}
+
+void MapperJITLinkMemoryManager::allowSingleSlab() {
----------------
jaredwy wrote:

The naming here seems a bit confusing, given secondslab actually means allow N slabs.

Could we perhaps call it something like setSlabPolicy and onSlabGrow or something? I think that at this point we only really have the two policies. Allow/deny? So we could perhaps simplify things a bit. 

Also could you pass some information like dylib name and other things that may be relevant to make the error message a bit easier to diagnose. 

https://github.com/llvm/llvm-project/pull/207970


More information about the llvm-commits mailing list