[PATCH] D130392: [Orc][JITLink] Slab based memory allocator to reduce RPC calls

[Anubhab Ghosh via Phabricator via llvm-commits]

argentite created this revision.
argentite added reviewers: lhames, sgraenitz.
Herald added subscribers: StephenFan, hiraditya.
Herald added a project: All.
argentite updated this revision to Diff 447747.
argentite marked an inline comment as done.
argentite added a comment.
argentite updated this revision to Diff 448300.
argentite retitled this revision from "[Orc][JITLink] Custom memory allocator to reduce RPC calls" to "[Orc][JITLink] Slab based memory allocator to reduce RPC calls".
argentite edited the summary of this revision.
argentite published this revision for review.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

When enough memory is not already reserved, lock the mutex while doing the RPC to prevent subsequent allocations to request new memory ranges


argentite added a comment.

Updated title and commit message



================
Comment at: llvm/lib/ExecutionEngine/Orc/MapperJITLinkMemoryManager.cpp:62
 
 void MapperJITLinkMemoryManager::allocate(const JITLinkDylib *JD, LinkGraph &G,
                                           OnAllocatedFunction OnAllocated) {
----------------
It looks like the algorithm here is:
1. lock
2. search for range
3. unlock
4. check if range found
5. if so then `CompleteAllocation`, otherwise reserve and `CompleteAllocation` in the callback.

The problem is that if we start off with two concurrent `allocate` calls we might allocate two different slabs, which we don't want to do. I think the allocator should do a blocking call to reserve under the lock instead. That'll hit the first caller hard, but it guarantees that we don't allocate more than one slab until/unless the first one fills up.

(We could also make this configurable too -- we want the slab allocator to be able to guarantee memory range constraints to enable use of arbitrary small code model code, but it's also useful as a performance optimization, so two arguments "slab size" and "allow concurrent reservations" would make sense. I think that should be a follow-up patch though).


Calling reserve() used to require an RPC call. This commit allows large
ranges of executor address space to be reserved. Subsequent calls to
reserve() will return subranges of already reserved address space while
there is still space available.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D130392

Files:
  llvm/include/llvm/ExecutionEngine/Orc/MapperJITLinkMemoryManager.h
  llvm/lib/ExecutionEngine/Orc/MapperJITLinkMemoryManager.cpp
  llvm/unittests/ExecutionEngine/Orc/MapperJITLinkMemoryManagerTest.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D130392.448300.patch
Type: text/x-patch
Size: 12333 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20220728/b3082366/attachment.bin>