Push WASM memory management to WasmModule
#656
Conversation
| @@ -674,17 +674,125 @@ void WasmModule::writeWasmEnvToMemory(uint32_t envPointers, uint32_t envBuffer) | |||
|
|
|||
| uint32_t WasmModule::growMemory(size_t nBytes) | |||
| { | |||
| throw std::runtime_error("growMemory not implemented"); | |||
| if (nBytes == 0) { | |||
There was a problem hiding this comment.
All the implementation in this file is copied from WAVMWasmModule with the necessary changes to make it runtime-agnostic.
| @@ -1008,198 +1008,56 @@ U32 WAVMWasmModule::mmapFile(U32 fd, size_t length) | |||
| return wasmPtr; | |||
| } | |||
|
|
|||
| U32 WAVMWasmModule::growMemory(size_t nBytes) | |||
| bool WAVMWasmModule::doGrowMemory(uint32_t pageChange) | |||
There was a problem hiding this comment.
This diff is very hard to read, but I have left the sense-checks that we can only do in WAVM. You can see the new code here.
| } else { | ||
| return module->growMemory(increment); | ||
| } | ||
| SPDLOG_WARN("SGX-WAMR sbrk does not allocate more memory"); |
There was a problem hiding this comment.
We don't really want to be growing memory outside the enclave. Memory management will have to be implemented inside the enclave.
There was a problem hiding this comment.
Should this be an error then?
There was a problem hiding this comment.
We still call this method from SGX code, so even if we do nothing we must not error out in order for functions to finish.
| } else { | ||
| return module->growMemory(increment); | ||
| } | ||
| SPDLOG_WARN("SGX-WAMR sbrk does not allocate more memory"); |
There was a problem hiding this comment.
Should this be an error then?
In this PR I introduce support for
mmap/munmapin WAMR. In the process, I push most of the memory management implementation fromWAVMWasmModuletoWasmModuleto avoid duplication between WAMR and WAVM.The implementation is still quite generic, and we can get away with few calls to the actual WASM runtime.