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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/ExecutionEngine/Orc/MapperJITLinkMemoryManager.cpp | ||
---|---|---|
62 | It looks like the algorithm here is:
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). |
When enough memory is not already reserved, lock the mutex while doing the RPC to prevent subsequent allocations to request new memory ranges
LGTM!
llvm/include/llvm/ExecutionEngine/Orc/MapperJITLinkMemoryManager.h | ||
---|---|---|
55–58 |
I didn't understand this comment? This is just the used memory list, right? Whether or not there's any memory associated with it on the controller side should be up to the mapper, rather than the allocator. | |
llvm/lib/ExecutionEngine/Orc/MapperJITLinkMemoryManager.cpp | ||
72–87 | I think this check should probably be dropped: We support JITing on a 32-bit controller for a 64-bit target, so you could request, e.g., an 8Gb zero-fill data section. That would overflow a size_t on the controller, but is still perfectly legal. On the other hand if you overflow the address scape for the executor then you'll definitely overflow the available space too, so you'll error out below anyway. | |
157 | There's no coalescing of the AvailableMemory list yet, so you'll get fragmentation in the allocator. I think that should be addressed in a follow-up patch though. |
I didn't understand this comment? This is just the used memory list, right? Whether or not there's any memory associated with it on the controller side should be up to the mapper, rather than the allocator.