docs(code-runtime-python): sync hostFrameParseCeiling example numbers to the 16x multiple

The hostFrameParseCeiling JSDoc and one load-gate test comment still quoted
the pre-16x derivation (~29 MiB for a ~300 MiB heap, ~14 MiB for a 128 MiB
old space). With HOST_PARSE_WORST_CASE_MULTIPLE = 16 the same hosts derive
~14 MiB and ~7 MiB (floor((176-64)/16)); protocol.spec.ts pins the 304 MiB
case at 15 MiB. Comment-only correction, no behavior change.
This commit is contained in:
Chinesezjc
2026-08-31 18:57:34 +08:00
parent 974fca9f5a
commit a8d8b8cddd
2 changed files with 2 additions and 2 deletions
@@ -355,7 +355,7 @@ const HOST_PARSE_BASELINE_BYTES = 64 * 1024 * 1024
* ≤64 MiB wide-object frame materializes several times that in property
* storage — so the effective cap is the smaller of the two. A default Node
* heap (~4 GiB) never binds; a constrained host (e.g.
* `--max-old-space-size=256` reports a ~300 MiB limit) lowers it to ~29 MiB,
* `--max-old-space-size=256` reports a ~300 MiB limit) lowers it to ~14 MiB,
* and the load gate rejects budgets that cannot cross it.
* @param heapLimit - the host's configured heap limit; the live
* `heap_size_limit` when omitted. A parameter so the derivation is unit
@@ -182,7 +182,7 @@ describe('PythonCodeRuntime — seam descriptors and misuse', () => {
// The load gate bounds the CHILD's build-and-encode under RLIMIT_AS; it
// does not bound the HOST's JSON.parse, which materializes several times a
// wide frame's raw bytes in property storage. In a child node with a
// 128 MiB old space the heap-derived frame cap is ~14 MiB, so a 50 MiB
// 128 MiB old space the heap-derived frame cap is ~7 MiB, so a 50 MiB
// budget is rejected at load even though the address-space gate alone
// would admit it (50 MiB * 12 = 600 MiB < 1 GiB - 64 MiB).
const script = [