diff options
author | Lang Hames <lhames@gmail.com> | 2025-10-13 12:33:16 +1100 |
---|---|---|
committer | GitHub <noreply@github.com> | 2025-10-13 12:33:16 +1100 |
commit | 7381558ef8b8639831dfdedf7edbd5e635afc85e (patch) | |
tree | 9420b5ffee84d75afd7a19fff7ed6f4a659d7e08 /llvm/lib/Object/XCOFFObjectFile.cpp | |
parent | 8d03a37b9844070b6ccd83aa7cc8b28e91f8d213 (diff) | |
download | llvm-7381558ef8b8639831dfdedf7edbd5e635afc85e.zip llvm-7381558ef8b8639831dfdedf7edbd5e635afc85e.tar.gz llvm-7381558ef8b8639831dfdedf7edbd5e635afc85e.tar.bz2 |
[orc-rt] Rename SimpleNativeMemoryMap finalize & deallocate. NFCI. (#163114)
This commit renames the "finalize" operation to "initialize", and
"deallocate" to "deinitialize".
The new names are chosen to better fit the point of view of the
ORC-runtime and executor-process: After memory is *reserved* it can be
*initialized* with some content, and *deinitialized* to return that
memory to the reserved region.
This seems more understandable to me than the original scheme, which
named these operations after the controller-side JITLinkMemoryManager
operations that they partially implemented. I.e.
SimpleNativeMemoryMap::finalize implemented the final step of
JITLinkMemoryManager::finalize, initializing the memory in the executor;
and SimpleNativeMemoryMap::deallocate implemented the final step of
JITLinkMemoryManager::deallocate, running dealloc actions and releasing
the finalized region.
The proper way to think of the relationship between these operations now
is that:
1. The final step of finalization is to initialize the memory in the
executor.
2. The final step of deallocation is to deinitialize the memory in the
executor.
Diffstat (limited to 'llvm/lib/Object/XCOFFObjectFile.cpp')
0 files changed, 0 insertions, 0 deletions