From f71f040258661cf9a902f8505b8e4ecf138a6ca0 Mon Sep 17 00:00:00 2001 From: "rivet-docs-sync[bot]" Date: Wed, 28 Oct 2026 18:29:47 +0000 Subject: [PATCH] docs(agentos): sync from rivet-dev/agentos@c746292 --- .../content/docs/architecture/networking.mdx | 2 +- .../docs/content/docs/resource-limits.mdx | 27 +++++++++++++++++++ 2 files changed, 28 insertions(+), 1 deletion(-) diff --git a/vendor/agentos/docs/content/docs/architecture/networking.mdx b/vendor/agentos/docs/content/docs/architecture/networking.mdx index cada2bd4..06bbe1f4 100644 --- a/vendor/agentos/docs/content/docs/architecture/networking.mdx +++ b/vendor/agentos/docs/content/docs/architecture/networking.mdx @@ -99,7 +99,7 @@ Guest networking is confined by three distinct controls plus the loopback-only d Guest listeners are reachable only over loopback (`127.0.0.1` / `::1`) inside the VM. - Binding to `0.0.0.0` or `::` does not widen this: the kernel normalizes the unspecified address down to loopback, so the listener still answers only on loopback. -- A connection that originates outside the loopback interface and targets a port the VM does not own is refused with `EACCES`, noting the port is not exempt. +- A guest TCP connection to a loopback port that no VM listener owns fails with `ECONNREFUSED`, as on Linux. A UDP send or connect to such a port fails with `EACCES`. Neither falls through to a host loopback service unless the port is listed in `loopbackExemptPorts`. - This confinement is independent of the permission policy. Even with the network allowed, a guest server stays loopback-only unless its port is explicitly exempted. ### Three stacked controls diff --git a/vendor/agentos/docs/content/docs/resource-limits.mdx b/vendor/agentos/docs/content/docs/resource-limits.mdx index b8b2b6f6..63df8c92 100644 --- a/vendor/agentos/docs/content/docs/resource-limits.mdx +++ b/vendor/agentos/docs/content/docs/resource-limits.mdx @@ -60,6 +60,12 @@ a clean stop. Close completion can no longer be confirmed, so the VM stays quarantined until the sidecar process restarts, even if local resource counts reach zero. Quarantined VMs count toward VM admission capacity. +Socket writes between processes in the same VM share the +`limits.resources.maxSocketBufferedBytes` budget. When the budget is full, a +write waits for the reader to drain it, like a Node.js socket write. If the +reader does not drain it within `limits.reactor.operationDeadlineMs`, the +write fails with `ETIMEDOUT` and an error that names that limit. + Limits are fixed for the life of a VM. To change them on a hosted VM, update the config and call `v1.vm.restart`. In the library, dispose the VM and create a new one with the new limits. The hosted actor also has a fixed ten-second @@ -79,6 +85,27 @@ file content is base64-encoded, so one `writeFile` or `writeFiles` call carries at most about 12 MiB of binary data. To move larger files, split them into several files or mount a host directory. +### Isolate memory + +Each V8 isolate that runs guest JavaScript or Python has two memory caps of the +same size: one for the V8 heap and one for `ArrayBuffer` memory, which also +backs typed arrays, `Buffer`, and `SharedArrayBuffer`. The size is +`limits.jsRuntime.v8HeapLimitMb` for JavaScript (128 MiB by default) and +`limits.python.maxOldSpaceMb` for Python. A script that goes past the heap cap +fails with `execution_heap_limit_exceeded`. An allocation that goes past the +`ArrayBuffer` cap throws `RangeError: Array buffer allocation failed`, and the +sidecar reports the `v8_array_buffer_bytes` limit warning. Other VMs on the +sidecar keep running in both cases. + +In JavaScript, WebAssembly memory and buffers that hold data from the host, +such as file contents, have a third cap of the same size. V8 checks it during +garbage collection. A script that goes past it fails with +`execution_heap_limit_exceeded`, and the sidecar reports the +`v8_external_memory_bytes` limit warning. Python keeps its interpreter memory +in WebAssembly, so this cap does not apply to Python. Shared WebAssembly +memory, resizable `ArrayBuffer`s, and growable `SharedArrayBuffer`s are not +counted toward any cap. + ### Sidecar memory On Linux with glibc, the sidecar returns memory freed by a disposed VM's V8