[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