Virtines Lit Review

Progress

pg. 0/19

Source Information

• Title: Isolating Functions at the Hardware Limit with Virtines
• Authors: Wanninger, Nicholas C. and Bowden, Joshua J. and Shetty, Kirtankumar and Garg, Ayush and Hale, Kyle C.
• Year: 2022
• Publication: EuroSys 2022
• PDF: Isolating Functions at the Hardware Limit with Virtines

General Notes

• Abstract Summary:
  • It is oftentimes useful to isolate code at the function invocation level. There are no existing mechanism for this, so enter virtines
  • Virtines are a general abstraction that allows you to run individual functions within an isolated VM
  • Also Wasp, an embeddable hypervisor that allows programmer to use virtines.

Why is it needed

• UDFs in databases, untrusted library functions in critical applications, and serveless functions
  • This isolation model is normally solved by resorting to repurposing off-the-shel mechanisms with mismatched design goals to suit their needs
    • UDFs run in a managed language (Java or JS)
    • Serveless platforms use containers to isolation users’ stateless function invocations
      • Cold start on serveless is huge with this model

Virtines

• Virtines are a new abstraction designed for isolating execution at function call granularity using hardware virtualization
  • Three components:
    • Toolchain-generated binary to run in a virtual context
    • Hypervisor that facilitate the VM’s only external access (Wasp)
    • Host program that specifies virtine isolation policies and drives Wasp
  • Honestly pretty simple, you embed virtines into your program
  • Virtines have a very minimal kernel-mode only os that changes depending on how many features you need

Optimization

• Standard OSes take a long time to boot
  • 30% of Linux kernel boot is spent scanning ACPI tables, configuring ACPI, enumerating PCI, and populating root.
  • Sometimes you can just cache a pre-booted environment
    • This is what makes virtines viable when combined with snapshotting.
• Real mode is far faster as there isn’t paging, etc., overhead

Implementation

• Wasp is an embedded micro hypervisor
• Just a library that host programs link against
• Doesn’t emulate entire x86 platform or device model
• Doesn’t provide libaries
• Hypercalls don’t emulate devices, instead provide high-level services
  • Vector to a predefined handler that can pass to host syscalls after filtering

Evaluation

• Baseline virtine (no snapshot): 6.6× slowdown vs native at fib(0); drops to ~1.03× at fib(25). Amortization point ~100μs of work
• Snapshotting gives ~2.5× speedup at fib(0), pushes amortization ~10× lower
• Image size is memory-bandwidth-bound past ~2MB (~6.8 GB/s, matches memcpy)
• HTTP server (7 hypercalls/req): only ~12% throughput drop with snapshotting
  • hypercall overhead is manageable if interactions are limited
• OpenSSL integration: ~1hr dev effort, 17× slowdown on AES-128 block cipher (memory-bound from snapshot copy, 16KB block = 16μs/invocation)
• Duktape JS: 137μs total latency with snapshot + no-teardown optimization (~1.5× over native baseline of 419μs)

Discussion

• Vespid (virtine-based OpenWhisk prototype) shows competitive cold-start vs vanilla containers, though Duktape vs V8 is apples-to-oranges
• Future: automatic call-graph cutting, copy-on-write snapshots, V8 port, nested virtines, distributed/migrateable virtines

Key Findings

• Caching + snapshotting are what make virtines practical
  • Without them overhead is too high for short-lived functions
• Hypercall overhead is acceptable if interactions are minimized and coarse-grained (POSIX-level, not device-level)
• Image size is the main remaining bottleneck; CoW would largely solve it

Critique/Gaps

• Cutting the call graph decision made by programmer, but possible to be made by compiler
• Snapshotting shares reset state across virtine instances (correctness footgun left to programmer)
• C extensions limited to single compilation unit
• Duktape doesn’t really compare to prod JS engines

Questions

• Wasp name inspired by Bhyve?
• Is caching pre-booted environment as simple as memset?

Relations

• unikernels
• hardware-virtualization

References (if any)

diff --git a/lit-reviews/wanninger2022isolating.md b/lit-reviews/wanninger2022isolating.md
index b78f9cb..74eece3 100644
--- a/lit-reviews/wanninger2022isolating.md
+++ b/lit-reviews/wanninger2022isolating.md
@@ -58,16 +58,55 @@ pg. 0/19
   - 30% of Linux kernel boot is spent scanning ACPI tables, configuring ACPI,
     enumerating PCI, and populating root.
   - Sometimes you can just cache a pre-booted environment
+    - This is what makes virtines viable when combined with snapshotting.
 - Real mode is far faster as there isn't paging, etc., overhead
 
+### Implementation
+
+- Wasp is an embedded micro hypervisor
+- Just a library that host programs link against
+- Doesn't emulate entire x86 platform or device model
+- Doesn't provide libaries
+- Hypercalls don't emulate devices, instead provide high-level services
+  - Vector to a predefined handler that can pass to host syscalls after
+    filtering
+
+### Evaluation
+
+- Baseline virtine (no snapshot): 6.6× slowdown vs native at fib(0); drops to
+  ~1.03× at fib(25). Amortization point ~100μs of work
+- Snapshotting gives ~2.5× speedup at fib(0), pushes amortization ~10× lower
+- Image size is memory-bandwidth-bound past ~2MB (~6.8 GB/s, matches memcpy)
+- HTTP server (7 hypercalls/req): only ~12% throughput drop with snapshotting
+  - hypercall overhead is manageable if interactions are limited
+- OpenSSL integration: ~1hr dev effort, 17× slowdown on AES-128 block cipher
+  (memory-bound from snapshot copy, 16KB block = 16μs/invocation)
+- Duktape JS: 137μs total latency with snapshot + no-teardown optimization
+  (~1.5× over native baseline of 419μs)
+
+Discussion
+
+- Vespid (virtine-based OpenWhisk prototype) shows competitive cold-start vs
+  vanilla containers, though Duktape vs V8 is apples-to-oranges
+- Future: automatic call-graph cutting, copy-on-write snapshots, V8 port, nested
+  virtines, distributed/migrateable virtines
+
 ## Key Findings
 
--
+- Caching + snapshotting are what make virtines practical
+  - Without them overhead is too high for short-lived functions
+- Hypercall overhead is acceptable if interactions are minimized and
+  coarse-grained (POSIX-level, not device-level)
+- Image size is the main remaining bottleneck; CoW would largely solve it
 
 ## Critique/Gaps
 
 - Cutting the call graph decision made by programmer, but possible to be made by
-  compilerkk
+  compiler
+- Snapshotting shares reset state across virtine instances (correctness footgun
+  left to programmer)
+- C extensions limited to single compilation unit
+- Duktape doesn't really compare to prod JS engines
 
 ## Questions
 
@@ -76,6 +115,7 @@ pg. 0/19
 
 ## Relations
 
--
+- [[../concepts/unikernels]]
+- [[../concepts/hardware-virtualization]]
 
 ## References (if any)