feat(vm-runner): out-of-process wasm compilation daemon

[jakmeier]

Sandboxed, memory-limited compilation for Wasmtime on Linux.

This is meant to be an optional setup that lives side-by-side with in-process compilation as an experiment for now.

The implementation is not complete, to keep the initial PR reasonably sized.
(Hint: Review it commit-by-commit.)

Follow-ups are planned for:

• Retry with a higher memory limit on a OOM crash
• Allow configuration of constants
• Metrics
• Check version compatibility between child and parent binaries

Questions that need to be resolved and might also need follow-ups:

• How to deal with WasmCompilationUnknownError? Now I treat them the same as WasmUnknownError, potentially committing it to the chain if it fails compilation on most nodes and validators. I'm not so happy about that and it's opposite to what we discussed in the last meeting on the topic. But it seems more consistent for an initial commit.
• Should we have a wallclock timeout on child startup and request processing?
• Should we avoid a second binary and run full neard as the daemon instead?
• Should we use sccomp for additional sandboxing

[codecov]

Codecov Report

❌ Patch coverage is 61.38889% with 278 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.15%. Comparing base (44f6c39) to head (2683bb9).

Files with missing lines	Patch %	Lines
...untime/near-vm-runner/src/compiler_daemon/child.rs	0.00%	76 Missing ⚠️
...ntime/near-vm-runner/src/compiler_daemon/parent.rs	75.09%	51 Missing and 14 partials ⚠️
...time/near-vm-runner/src/compiler_daemon/sandbox.rs	0.00%	63 Missing ⚠️
runtime/near-vm-runner/src/runner.rs	40.00%	11 Missing and 1 partial ⚠️
...ime/near-vm-runner/src/compiler_daemon/protocol.rs	54.54%	7 Missing and 3 partials ⚠️
runtime/near-vm-runner/src/wasmtime_runner/mod.rs	87.17%	8 Missing and 2 partials ⚠️
runtime/runtime/src/function_call.rs	0.00%	9 Missing ⚠️
core/async/src/thread_pool.rs	65.21%	8 Missing ⚠️
nearcore/src/lib.rs	93.10%	4 Missing and 2 partials ⚠️
runtime/runtime/src/metrics.rs	0.00%	6 Missing ⚠️
... and 6 more

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #16067      +/-   ##
==========================================
- Coverage   73.24%   73.15%   -0.10%     
==========================================
  Files         856      862       +6     
  Lines      188398   189049     +651     
  Branches   188398   189049     +651     
==========================================
+ Hits       137996   138301     +305     
- Misses      45996    46316     +320     
- Partials     4406     4432      +26     

Flag	Coverage Δ
pytests-nightly	1.22% <0.16%> (-0.01%)	⬇️
unittests	69.83% <61.38%> (-0.05%)	⬇️
unittests-nightly	69.84% <61.38%> (-0.05%)	⬇️
unittests-spice	65.45% <61.38%> (-0.05%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jakmeier]

Regarding the chosen size limits, I ran experiments on jakmeier/experiments_on_wasmtime_memory_usage against >3000 mainnet contracts.

Results show that on average, more than 6 threads doesn't meaningfully reduce compilation time. Virtual memory usage (what is limited by RLIMIT_AS in the PR) does keep increasing with more allocated threads though. Hence I chose 6 threads per worker so we don't have to overallocate too much.

With 6 threads, maximum virtual memory usage is 596.46 MB for mainnet contracts. (Crafted contracts we identified as being memory hungry actually stay below that, now that we have limits in place and use Winch.)

Compilation time

Threads	n	mean	median	min	max	stdev
2	10386	74.90 ms	64.92 ms	0.25 ms	403.26 ms	47.01 ms
4	10386	43.77 ms	38.48 ms	0.31 ms	226.10 ms	26.52 ms
6	10386	33.69 ms	29.71 ms	0.33 ms	198.81 ms	20.14 ms
8	10386	28.73 ms	25.49 ms	0.41 ms	147.49 ms	16.86 ms
10	10386	25.31 ms	22.42 ms	0.47 ms	133.61 ms	14.76 ms

Peak memory usage (RSS)

Threads	n	mean	median	min	max	stdev
2	10386	39.09 MB	34.40 MB	4.78 MB	169.96 MB	20.15 MB
4	10386	39.30 MB	34.51 MB	4.80 MB	170.18 MB	20.13 MB
6	10386	39.72 MB	34.94 MB	4.87 MB	170.87 MB	20.17 MB
8	10386	40.10 MB	35.37 MB	4.91 MB	171.54 MB	20.23 MB
10	10386	40.63 MB	35.88 MB	4.96 MB	170.02 MB	20.33 MB

Peak virtual memory usage

Threads	n	mean	median	min	max	stdev
2	10386	212.76 MB	210.68 MB	144.27 MB	286.96 MB	15.74 MB
4	10386	315.89 MB	303.63 MB	212.28 MB	465.53 MB	27.90 MB
6	10386	448.83 MB	434.79 MB	408.34 MB	596.46 MB	30.64 MB
8	10386	580.26 MB	567.03 MB	540.37 MB	733.66 MB	28.88 MB
10	10386	724.99 MB	710.61 MB	672.40 MB	877.72 MB	42.81 MB

I also plotted compilation time with different thread numbers grouped by effective WASM size, to ensure the global average and mean don't hide a meaningful improvement on large contracts. Looks like 6 threads hits diminishing returns on all size buckets.

[ssavenko-near]

How to deal with WasmCompilationUnknownError? Now I treat them the same as WasmUnknownError, potentially committing it to the chain if it fails compilation on most nodes and validators. I'm not so happy about that and it's opposite to what we discussed in the last meeting on the topic.

I recall we did not converge on this topic during the meeting. I actually favor the currently implemented option, but that's definitely something which is worth a deeper dive.