near_vm: reuse contract data/memory between contract executions #10851
Assignees
Labels
A-contract-runtime
Area: contract compilation and execution, virtual machines, etc
T-contract-runtime
Team: issues relevant to the contract runtime team
Comments
nagisa
added
A-contract-runtime
|
CC: @Ekleog-NEAR |
Hackish experiment resultTL;DRReusing the same memories leads to us spending much more time zeroing out memory. As I originally feared, most of the time in mmap was likely actually the kernel zeroing out only the used parts of the memory, and once we stop relying on it we need to zero out much more. So we most likely should not apply just this change as initially considered. However, if we are able to reduce the initial size of the wasm memory (which would require a protocol change and might break contracts) from 64MiB to 64kiB, then we could hope for some speedup on congested shards. An upper bound would be 60%, the numbers from shard 2. However this is likely a way overestimated upper bound, because I could not figure out how to easily compare the hackish code and the non-hackish code, due to the protocol version change. In particular, my guess would be my benchmarks actually lead to the contracts under test to start failing at startup, and thus not actually executing. Shard 4 exhibited a 15% speedup, which sounds like a more likely upper bound. My suggestion would be to drop this line of changes, because either:
Non-protocol-change attemptCode usedOn top of commit 4c0aa98, this patch: diff --git a/Cargo.lock b/Cargo.lock
index 5b2906165..1e0355699 100644
--- a/Cargo.lock
+++ b/Cargo.lock
@@ -4931,11 +4931,13 @@ dependencies = [
"bolero",
"borsh 1.0.0",
"cov-mark",
+ "crossbeam",
"ed25519-dalek",
"enum-map",
"expect-test",
"finite-wasm",
"hex",
+ "lazy_static",
"lru 0.12.3",
"memoffset 0.8.0",
"near-crypto",
diff --git a/runtime/near-vm-runner/Cargo.toml b/runtime/near-vm-runner/Cargo.toml
index 1e6be8d23..658296ec2 100644
--- a/runtime/near-vm-runner/Cargo.toml
+++ b/runtime/near-vm-runner/Cargo.toml
@@ -17,9 +17,11 @@ anyhow = { workspace = true, optional = true }
base64.workspace = true
bn.workspace = true
borsh.workspace = true
+crossbeam.workspace = true
ed25519-dalek.workspace = true
enum-map.workspace = true
finite-wasm = { workspace = true, features = ["instrument"], optional = true }
+lazy_static.workspace = true
lru = "0.12.3"
memoffset.workspace = true
num-rational.workspace = true
diff --git a/runtime/near-vm-runner/src/near_vm_runner.rs b/runtime/near-vm-runner/src/near_vm_runner.rs
index 0940bd629..b10ffb331 100644
--- a/runtime/near-vm-runner/src/near_vm_runner.rs
+++ b/runtime/near-vm-runner/src/near_vm_runner.rs
@@ -438,11 +438,15 @@ impl NearVM {
},
)?;
- let mut memory = NearVmMemory::new(
+ lazy_static::lazy_static! {
+ static ref MEMORIES: crossbeam::queue::ArrayQueue<NearVmMemory> = crossbeam::queue::ArrayQueue::new(16);
+ }
+ let mut memory = MEMORIES.pop()
+ .unwrap_or_else(|| NearVmMemory::new(
self.config.limit_config.initial_memory_pages,
self.config.limit_config.max_memory_pages,
)
- .expect("Cannot create memory for a contract call");
+ .expect("Cannot create memory for a contract call"));
// FIXME: this mostly duplicates the `run_module` method.
// Note that we don't clone the actual backing memory, just increase the RC.
let vmmemory = memory.vm();
@@ -459,7 +463,18 @@ impl NearVM {
if let Err(e) = result {
return Ok(VMOutcome::abort(logic, e));
}
- closure(vmmemory, logic, &artifact)
+ let res = closure(vmmemory, logic, &artifact);
+ let mut mem = memory.0.vmmemory();
+ unsafe {
+ let mem = mem.as_mut();
+ mem.base.write_bytes(0, mem.current_length);
+ // Tried both with and without this line, with similar results.
+ // My intuition is, this line should actually be present, so the detailed evaluation was performed
+ // with it on.
+ mem.current_length = self.config.limit_config.initial_memory_pages as usize * WASM_PAGE_SIZE;
+ }
+ let _ = MEMORIES.push(memory);
+ res
}
Err(e) => Ok(VMOutcome::abort(logic, FunctionCallError::CompilationError(e))),
}With the
|
|
Closing this as a consequence of the above message. Future work can be tracked with #11033 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently we reuse memory maps that we allocate for storing compiled machine code for the contracts. This has been found to work great and improves the performance by a great degree. This is because the kernel needs to do quite a bit of accounting each time memory maps are set up.
Fortunately for us, the contracts all have a very specific amount of memory available to them. So we could allocate the necessary number of contract memories up-front and lock them so that they are not paged out (paging the memories back in => overhead)
The only thing we need to be careful about is that unlike code memories (which are not observable by the contracts), the data memories must be zeroed out after use in order to prevent leaking the data between contracts through them.
This could reduce the total
execute_function_calltime by roughly 20% on average in the post 1.39 world (provided that other relevant caches kick in.)The text was updated successfully, but these errors were encountered: