@bridge4dev/runner 0.57.0 → 0.58.1

package/dist/session-allocator.js

@@ -0,0 +1,492 @@
+import { SESSION_MEMORY_BAND_BYTES, sessionMemoryLadder } from './session-cage.js';
+const MIB = 1024 * 1024;
+/**
+ * How much memory each live session may use, decided from what is actually free
+ * (#398 S3, ticket #398).
+ *
+ * The number this replaces was `max(pot / 3, 2 GiB)`, computed ONCE at daemon
+ * start and never again. The divisor came from `maxSessions` defaulting to three
+ * and from nothing else, so a lone session on an idle machine got a third of the
+ * pot and the other two thirds sat unused — the owner's complaint in #398, word
+ * for word: «ночью машина свободна ~9 ГБ, а сессии всё равно нельзя выйти за
+ * 2.5 ГБ».
+ *
+ * **The decisive idea is three levels, and it has to be understood before any of
+ * the arithmetic below.** Today a session has two numbers, the brake and the
+ * wall, and both of the jobs — «do not crowd your neighbour» and «do not kill
+ * the machine» — are being asked of them at once. That is unsatisfiable: for a
+ * lone session to take nearly the whole pot its brake must be nearly the whole
+ * pot, and then two such sessions overflow the pot between them without either
+ * being braked — and what overflows is the SLICE, where the victim is chosen by
+ * the kernel and the one that dies is not the one at fault (measured, #387).
+ *
+ * So there are three, the way every grown-up scheduler has three:
+ *
+ *  - **the guarantee** (`MemoryLow`) — small and untouchable. The sum of the
+ *    guarantees has to fit in the pot, and this is the ONLY place a sum is
+ *    checked. It answers «how much will not be taken from me».
+ *  - **the brake** (`MemoryHigh`) — large and DELIBERATELY oversold. Every
+ *    session may grow into everything that is free right now. The sum of the
+ *    brakes is greater than the pot, and that is not a mistake.
+ *  - **the collective brake on the slice** (`MemoryHigh` on
+ *    `devbridge-sessions.slice`, `service-unit.ts`) — the thing that makes the
+ *    overselling safe. As the sessions together approach the pot the kernel
+ *    slows all of them and reclaims first from whoever is above their guarantee,
+ *    so the hard ceiling — where the OOM killer picks — is never reached.
+ *  - **the wall** (`MemoryMax`) — still one guarantee below the pot, so a lone
+ *    runaway meets ITS OWN wall before the shared pot overflows (rule of #387).
+ *
+ * Overselling the brakes WITHOUT the collective brake on the slice is a bug, not
+ * a solution. The two halves are one change, and {@link allocateSessionMemory}
+ * refuses to oversell when the caller reports that the slice has no live
+ * `MemoryHigh` — see {@link AllocatorMachine.collectiveBrake}.
+ */
+/**
+ * What one session is guaranteed and will not have taken away.
+ *
+ * 2 GiB, sized over the 1571 MB peak measured for a workspace `pnpm typecheck`
+ * in this monorepo. A dev server that cannot run one of those is not a dev
+ * server, so this is the number below which a session is not worth starting.
+ */
+export const SESSION_GUARANTEE_BYTES = 2048 * MIB;
+/**
+ * Growth allowance over what a session already holds.
+ *
+ * The same 1.25 `service-unit.ts` uses for the ceiling it writes over a cgroup's
+ * current usage, and for the same reason: a limit at exactly what is held is a
+ * limit that is already breached.
+ */
+export const SESSION_HEADROOM_OVER_HOLD = 1.25;
+/**
+ * The floor under the BRAKE, over what a session already holds — 1.05, and it
+ * is a different number from the one above on purpose (#398 §8, #403).
+ *
+ * The wall may sit a quarter above the hold: it is a hard limit, and headroom
+ * there costs nothing. The brake may not, because it is followed every tick: at
+ * 1.25 a session that merely holds its ground has its brake RAISED on every
+ * pass, `addMemoryTo` reads that as «the machine found it more memory», and the
+ * stall deadline resets for ever — measured in the suite, four tests waiting
+ * for a stop that could no longer come.
+ *
+ * 1.05 is enough for the one thing this floor is for: `memory.current` counts
+ * page cache, so a brake at exactly the anonymous hold is already breached.
+ */
+export const SESSION_BRAKE_OVER_HOLD = 1.05;
+/**
+ * The step the DIVIDED guarantee is rounded down to — 64 MiB (#403).
+ *
+ * `MemoryLow` is the one number here with no dead zone of its own, on purpose:
+ * a guarantee is what a person is promised, and a promise that lags a tick
+ * behind the machine is worse than one that follows it. But the divided
+ * guarantee is `pool / n`, and the pool follows `MemAvailable`, which breathes:
+ * measured on a hungry machine with two sessions, a pot of 3800 MiB and 11 MiB
+ * of breathing wrote `MemoryLow` on ten ticks out of ten where the code before
+ * these fixes wrote it on one.
+ *
+ * Rounding down rather than to nearest, because the sum of the guarantees is
+ * the one sum in this module that has to fit inside the pot.
+ */
+export const GUARANTEE_STEP_BYTES = 64 * 1024 * 1024;
+/** The divided guarantee, quantised so it does not breathe with `MemAvailable`. */
+function quantiseGuarantee(bytes) {
+    return Math.max(1, Math.floor(bytes / GUARANTEE_STEP_BYTES) * GUARANTEE_STEP_BYTES);
+}
+/** Below this pot the machine is honestly single-session — see the formula. */
+export function hungryPotBytes(baseBand) {
+    return 2 * SESSION_GUARANTEE_BYTES + baseBand;
+}
+/** The band this machine uses before any session-specific widening. */
+export function baseBandBytes(oomContinue) {
+    return oomContinue ? SESSION_MEMORY_BAND_BYTES : 512 * MIB;
+}
+function clamp(value, low, high) {
+    return Math.min(Math.max(value, low), high);
+}
+/**
+ * The whole decision, as a pure function of the numbers.
+ *
+ * Kept pure and kept here, away from every timer and socket, because what it has
+ * to be is CORRECT on machines nobody has: the formula travels with the runner
+ * to every customer's dev server, and the last two times a memory rule shipped
+ * it was reasonable on the author's machine and destructive somewhere else
+ * (#387: the victim was the neighbour; `service-unit.ts:314`: a 4 GB machine got
+ * `MemoryHigh == MemoryMax`). So the fleet's profiles are fixtures, and the
+ * eight properties below are tests rather than comments.
+ */
+export function allocateSessionMemory(machine, sessions, knobs = {}) {
+    const G = Math.max(1, knobs.guaranteeBytes ?? SESSION_GUARANTEE_BYTES);
+    const baseBand = baseBandBytes(machine.oomContinue);
+    const held = sessions.reduce((sum, s) => sum + Math.max(0, s.holdBytes), 0);
+    const current = sessions.reduce((sum, s) => sum + Math.max(0, s.currentBytes), 0);
+    // The live pot. `MemAvailable` cannot see what our own cgroups hold, so it is
+    // added back; the machine's reserve comes off; and the slice's own ceiling is
+    // the hard cap, because that is what systemd is actually enforcing over all
+    // sessions together. Never rewritten live — a slice rewritten under live
+    // sessions kills them (blocker found by QA on 07.09).
+    const pot = machine.potBytes ?? Number.POSITIVE_INFINITY;
+    const measured = machine.availableBytes + current - machine.reserveBytes;
+    // The floor is what the sessions already hold: a pot below that is not a pot,
+    // it is a number that would have to kill somebody to become true.
+    /**
+     * FLOORED, and this is not tidiness.
+     *
+     * `machineReserveBytes` is `max(1.5 GiB, total × 0.15)`, and on any machine
+     * with more than 10 GiB of RAM the second term wins and is FRACTIONAL
+     * (12541489152 × 0.15 = 1881223372.8). The fraction travelled through the pot
+     * into the brake and the wall, and systemd was handed
+     * `MemoryHigh=6350946099.200001`.
+     *
+     * **Корректировка 10.09.2026.** Проверка, ради которой это писалось, сначала
+     * назвала это блокером — «systemd такое отвергнет, на парке не записалось бы
+     * ничего». Замер показал обратное: systemd десятичное значение принимает.
+     * Пол всё равно нужен, но по другой причине: то, что systemd принял, он
+     * округляет по-своему, и обратно читается уже другое число — а согласование
+     * лимитов сравнивает записанное с прочитанным точным равенством. Дробь
+     * означала бы «не совпало» на каждом тике и запись свойств по кругу.
+     *
+     * Оставлено здесь дословно, потому что в этом проекте комментарий-замер
+     * читают как факт: неверное обоснование в комментарии живёт дольше, чем
+     * неверный код.
+     */
+    const poolBytes = Math.floor(Math.max(Math.min(pot, measured), held, G));
+    const freeBytes = Math.max(0, poolBytes - held);
+    const guaranteesFit = Math.max(0, Math.floor(poolBytes / G));
+    const n = Math.max(1, sessions.length);
+    const hungry = poolBytes < hungryPotBytes(baseBand);
+    // The guarantee. The ONE sum that is checked — and when it does not fit, the
+    // session still starts (D9) and is told it is in a crowd.
+    const guaranteeFits = n * G <= poolBytes;
+    const guarantee = guaranteeFits ? G : quantiseGuarantee(Math.floor(poolBytes / n));
+    /**
+     * The conservative fallback, and why it exists at all.
+     *
+     * Overselling the brakes is safe ONLY while the slice carries a live
+     * `MemoryHigh`. On a systemd where the drop-in never applied, the slice reads
+     * `MemoryMax=infinity` and overflowing it ends in a kill, not in throttling —
+     * and the kernel picks the victim across the whole slice. So a machine that
+     * cannot prove it has the collective brake gets roughly today's behaviour
+     * instead: the pot divided by the number of sessions, never fewer than three.
+     */
+    const share = Math.floor(poolBytes / Math.max(3, n));
+    const out = sessions.map((session) => {
+        const hold = Math.max(0, session.holdBytes);
+        /**
+         * The owner's emergency switch, and it gives back the OLD numbers — both of
+         * them, computed the old way (#398 S7, B1).
+         *
+         * `adaptive_memory = false` is documented as «back to what 0.55.0 did», and
+         * that is the whole value of it: a switch out of a bad night has to land
+         * somewhere known. What it did instead was route only the BRAKE through the
+         * old formula, leave the wall to the new one, and compute both from the
+         * LIVE pool rather than from the pot. Measured on the DEVbridge profile:
+         * brake 2840 as in 0.55.0, wall 3096 where 0.55.0 gave 5681 — a switch that
+         * halves your ceiling is not a way back.
+         *
+         * `sessionMemoryLadder` IS the 0.55.0 pair, and it is the same function the
+         * daemon-start snapshot uses, so there is one definition of «the old
+         * behaviour» rather than a re-derivation of it.
+         */
+        if (knobs.adaptive === false) {
+            const ladder = sessionMemoryLadder(machine.potBytes);
+            // The owner's ceiling still applies — a switch back to the old formula is
+            // not a switch out of the owner's own limit (#398 S7, B2). Never under
+            // what the session holds, for the reason every floor here exists.
+            const capped = Math.min(ladder.highBytes, knobs.sessionMaxBytes ?? Number.POSITIVE_INFINITY);
+            const brake = Math.floor(Math.max(capped, hold * SESSION_BRAKE_OVER_HOLD));
+            const wall = Math.floor(Math.max(ladder.maxBytes, brake + baseBand));
+            return {
+                id: session.id,
+                guaranteedBytes: Math.min(guarantee, brake),
+                brakeBytes: brake,
+                wallBytes: wall,
+                swapBytes: machine.swapBytes,
+                bandBytes: baseBand,
+                tight: !guaranteeFits,
+            };
+        }
+        if (hungry) {
+            // Honestly one session at a time. No `G` floor under the brake here: on a
+            // 2 GiB pot a brake of 2048 would sit ABOVE a wall of 1792 and the ladder
+            // would be upside down. The band stays even here — a wall equal to the pot
+            // would hand the choice of victim back to the kernel (D4).
+            const band = machine.oomContinue
+                ? baseBand
+                : Math.max(baseBand, Math.floor(poolBytes * 0.25));
+            /**
+             * …but NEVER below what this session already holds, and that omission was
+             * a blocker found by the independent review of 10.09.2026.
+             *
+             * A session holding 2900 MiB on a 2900 MiB pot was handed a wall of
+             * 2644 MiB — and lowering `MemoryMax` under what a process holds ends it
+             * in seconds (measured on this host: a scope holding 200 MiB, `MemoryMax`
+             * set to 64 MiB, the process read «Killed», the unit went `inactive`).
+             * The tight machine is exactly where this bites, because there the pot IS
+             * roughly what the session holds.
+             */
+            /**
+             * The floor is `hold × 1.05`, not a bare `hold` — the constant exists for
+             * exactly this and the plan says so (§8): «a limit at exactly what is held
+             * is a limit that is already breached».
+             *
+             * `memory.current` counts page cache too, so a brake set to the anonymous
+             * `hold` is a scope that starts above its own brake: constant reclaim,
+             * PSI climbing, and the stall detector of S2 seeing a session it cannot
+             * help. Found reviewing these very fixes (#403).
+             */
+            const floorOfHold = Math.floor(hold * SESSION_BRAKE_OVER_HOLD);
+            /**
+             * The owner's ceiling applies here too (#398 S7, B2).
+             *
+             * The hungry branch returns before the rest of the function, so both
+             * knobs used to be simply skipped on a tight machine — and a tight
+             * machine is exactly where an owner reaches for one: «leave room for the
+             * database, whatever the agents want». The floor under it stays what it
+             * is everywhere else, because a ceiling under what a session already
+             * holds kills it rather than limits it.
+             */
+            const ownerCapHere = knobs.sessionMaxBytes ?? Number.POSITIVE_INFINITY;
+            const brake = Math.floor(Math.max(1, Math.min(Math.max(poolBytes - 2 * band, 1), ownerCapHere), floorOfHold));
+            /**
+             * The pot is the cap, EXCEPT where honouring it would put the wall under
+             * what the session holds — and then the wall wins.
+             *
+             * The trade is the one this module makes everywhere: an oversold limit is
+             * safe, a killed honest session is not recoverable. On a hungry machine it
+             * costs nothing at all, because there is by definition at most one session
+             * in the slice: if the slice's own ceiling binds first, the victim the
+             * kernel picks IS this session, so there is no neighbour to harm.
+             */
+            const potCap = pot === Number.POSITIVE_INFINITY ? poolBytes + band : Math.floor(pot);
+            const wall = Math.floor(Math.max(brake + band, Math.min(Math.max(poolBytes - band, floorOfHold + band), potCap)));
+            return {
+                id: session.id,
+                /**
+                 * The share, not the constant — the same review found three sessions on
+                 * a 2048 MiB pot each being promised 2048 MiB. 4608 MiB of promises in
+                 * a pot of 2048, and the sum of the guarantees is the ONE sum in this
+                 * module that has to fit.
+                 */
+                guaranteedBytes: Math.max(1, Math.min(G, brake, quantiseGuarantee(Math.floor(poolBytes / n)))),
+                brakeBytes: brake,
+                wallBytes: wall,
+                swapBytes: machine.swapBytes,
+                bandBytes: band,
+                tight: !guaranteeFits,
+            };
+        }
+        // The brake this session WANTS: everything it holds plus everything nobody
+        // holds. This is the whole point of the stage — a lone session on an idle
+        // machine asks for nearly the whole pot, and gets it.
+        //
+        // …unless the owner has switched the whole thing off (#398 S6), and then it
+        // is exactly the number 0.55.0 shipped: `max(pot / 3, 2 GiB)`. The switch
+        // has to give back the OLD behaviour and not an approximation of it, or it
+        // is not a way out of a bad night.
+        // The `adaptive === false` case never reaches here — it returns above, with
+        // the 0.55.0 pair whole.
+        const desired = machine.collectiveBrake ? hold + freeBytes : share;
+        const band = machine.oomContinue
+            ? baseBand
+            : Math.max(baseBand, Math.floor(Math.max(desired, G) * 0.25));
+        /**
+         * The ceiling of the brake, PER SESSION.
+         *
+         * A common `poolBytes − G` for everyone was a trap the first draft fell
+         * into: the pool is floored by what the sessions hold, so on a crowded
+         * machine `pool − G` comes out BELOW what one session already has. Worked
+         * example: a session holding 5000 MiB with nothing free, pool 5000, common
+         * ceiling 2952 — the formula would have handed a live session with five
+         * gigabytes in hand a brake of 2696 and a wall of 2952, which kills it in
+         * seconds (measured: `MemoryMax` lowered under what a process holds ends it).
+         */
+        const top = Math.floor(Math.min(Math.max(Math.floor(hold * SESSION_HEADROOM_OVER_HOLD) + band, poolBytes - G), pot === Number.POSITIVE_INFINITY ? poolBytes : pot));
+        /**
+         * `top − band`, and the `− band` is not decoration.
+         *
+         * With both the brake and the wall capped at `pool − G`, the headline case
+         * of the whole plan — one session on a free machine — produced
+         * `MemoryHigh == MemoryMax`: the 0.54.0 kill line the entire stage exists to
+         * remove.
+         */
+        const ownerCap = knobs.sessionMaxBytes ?? Number.POSITIVE_INFINITY;
+        /**
+         * The floor under the brake is the guarantee OR what the session already
+         * holds, whichever is larger.
+         *
+         * The independent review of 10.09.2026 found the second half missing: on a
+         * machine that answers `sessionOomContinue: false` the band is a quarter of
+         * the brake, and `top − band` came out below a session's own `hold` — which
+         * puts a live session under its brake the moment the number is written, i.e.
+         * throttles it for having done nothing.
+         */
+        const floorOfBrake = Math.max(guarantee, Math.floor(hold * SESSION_BRAKE_OVER_HOLD));
+        const brake = Math.floor(clamp(Math.min(desired, ownerCap), floorOfBrake, Math.max(floorOfBrake, Math.min(top - band, ownerCap))));
+        /**
+         * The band between the brake and the wall is never given up, even when the
+         * pot is the thing in the way (decision D5 of `runner-cage-authority.md`,
+         * 10.09.2026).
+         *
+         * Measured on the profile of vmi2502773: a pot of 6835 MiB under a session
+         * holding 6000 gave `MemoryHigh=6000` and `MemoryMax=6835` — a band of 835
+         * where this machine's band is 1708. And the next tick made it worse:
+         * `planLimitMove` refuses to leave a wall under `brake + band` and would
+         * raise the wall to 7708, ABOVE the pot, which then travelled into the
+         * frame and onto the machine card.
+         *
+         * So the choice is made here and made once: an oversold wall is safe (the
+         * slice's own ceiling still binds, and the victim the kernel picks inside
+         * this scope is this session), while a brake equal to the wall means no
+         * braking at all — the session hits the hard limit with nothing in between,
+         * which is the 0.54.0 behaviour #387 was written to end.
+         */
+        const wallCeiling = pot === Number.POSITIVE_INFINITY ? poolBytes + band : Math.floor(pot);
+        const wallWanted = Math.max(brake + band, Math.floor(hold * SESSION_HEADROOM_OVER_HOLD) + band);
+        const wall = Math.floor(Math.max(brake + band, Math.min(wallWanted, wallCeiling)));
+        return {
+            id: session.id,
+            guaranteedBytes: guarantee,
+            brakeBytes: brake,
+            wallBytes: wall,
+            swapBytes: machine.swapBytes,
+            bandBytes: band,
+            tight: !guaranteeFits,
+        };
+    });
+    return {
+        sessions: out,
+        poolBytes,
+        heldBytes: held,
+        freeBytes,
+        guaranteesFit,
+        conservative: !machine.collectiveBrake,
+        hungry,
+    };
+}
+/** Ticks in a row a session must ask to shrink before its wall comes down. */
+export const SHRINK_TICKS_TO_LOWER = 4;
+/**
+ * Neither number moves for less than this — `max(256 MiB, 10 %)`.
+ *
+ * Every write is a `systemctl` call, and the bus was measured at 2.7 s under
+ * load. A dead zone is what keeps a pot that breathes by a few megabytes from
+ * costing a bus call per session per tick.
+ */
+export function deadZoneBytes(value) {
+    return Math.max(256 * MIB, Math.floor(value * 0.1));
+}
+/**
+ * What to actually write, given what is already in force.
+ *
+ * Up is free and immediate: memory nobody is using costs nobody anything.
+ * Down is where every rule lives.
+ */
+export function planLimitMove(written, wanted, holdBytes, 
+/**
+ * Does this systemd take `MemoryLow=` at all? (#398 S3)
+ *
+ * False costs the machine its guarantees and nothing else. It has to be
+ * honoured HERE and not only at spawn, because every property goes to systemd
+ * in ONE `set-property` call: a single directive this systemd refuses would
+ * take the brake and the wall down with it, every tick, for every session.
+ */
+memoryLow = true) {
+    const hold = Math.max(0, holdBytes);
+    if (written === null) {
+        return {
+            brakeBytes: wanted.brakeBytes,
+            wallBytes: wanted.wallBytes,
+            // Zero when nothing writes `MemoryLow` on this machine (#403): the field
+            // means «what is in force», and a guarantee nobody wrote is not in force.
+            // The card and the agent's prompt both read this, and both were naming a
+            // guarantee on machines whose systemd never took one.
+            guaranteedBytes: memoryLow ? wanted.guaranteedBytes : 0,
+            swapBytes: wanted.swapBytes,
+            holdBytes: hold,
+            shrinkTicks: 0,
+            properties: [
+                ...(memoryLow ? [`MemoryLow=${wanted.guaranteedBytes}`] : []),
+                `MemoryHigh=${wanted.brakeBytes}`,
+                `MemoryMax=${wanted.wallBytes}`,
+                `MemorySwapMax=${wanted.swapBytes}`,
+            ],
+            lowered: false,
+        };
+    }
+    // The brake. Down is allowed on the same tick, but only ever down to what is
+    // unused: never under the guarantee, and never onto a session that is sitting
+    // on its memory right now.
+    const brakeFloor = Math.max(wanted.guaranteedBytes, Math.floor(hold * 1.05));
+    const nextBrake = wanted.brakeBytes >= written.brakeBytes
+        ? wanted.brakeBytes
+        : Math.max(wanted.brakeBytes, brakeFloor);
+    /**
+     * The wall. Down ONLY from the session's own shrinking, never because a
+     * neighbour arrived — that is a separate rule and not a consequence of the
+     * one above. Without it a session honestly holding 500 MB and about to grow
+     * would be given a wall sized by its past.
+     */
+    const wallFloor = Math.floor(hold * 1.5);
+    /**
+     * …and «asked to shrink» means THIS SESSION shrank, not «the formula wants
+     * less». A neighbour arriving makes the formula want less for everybody, and
+     * a session that is honestly holding 500 MB and about to grow would then be
+     * given a wall sized by its past.
+     */
+    const shrankItself = hold < written.holdBytes;
+    // …and `written.holdBytes` is what the session held WHEN THE WALL WAS WRITTEN,
+    // not on the previous tick — see the assignment at the end of this function.
+    const wantsLowerWall = wanted.wallBytes < written.wallBytes && shrankItself;
+    const shrinkTicks = wantsLowerWall ? written.shrinkTicks + 1 : 0;
+    let nextWall = written.wallBytes;
+    if (wanted.wallBytes >= written.wallBytes) {
+        nextWall = wanted.wallBytes;
+    }
+    else if (shrinkTicks >= SHRINK_TICKS_TO_LOWER && wanted.wallBytes >= wallFloor) {
+        nextWall = wanted.wallBytes;
+    }
+    // A wall under the brake is a kill line again.
+    if (nextWall < nextBrake + wanted.bandBytes)
+        nextWall = nextBrake + wanted.bandBytes;
+    const properties = [];
+    if (Math.abs(nextBrake - written.brakeBytes) >= deadZoneBytes(written.brakeBytes)) {
+        properties.push(`MemoryHigh=${nextBrake}`);
+    }
+    if (Math.abs(nextWall - written.wallBytes) >= deadZoneBytes(written.wallBytes)) {
+        properties.push(`MemoryMax=${nextWall}`);
+    }
+    if (memoryLow && wanted.guaranteedBytes !== written.guaranteedBytes) {
+        properties.push(`MemoryLow=${wanted.guaranteedBytes}`);
+    }
+    // No dead zone on swap: it changes only when the machine itself does — a swap
+    // file appearing or going away — and every such change matters (see
+    // `WrittenLimits.swapBytes`).
+    if (wanted.swapBytes !== written.swapBytes) {
+        properties.push(`MemorySwapMax=${wanted.swapBytes}`);
+    }
+    const brakeOut = properties.some((p) => p.startsWith('MemoryHigh='))
+        ? nextBrake
+        : written.brakeBytes;
+    const wallOut = properties.some((p) => p.startsWith('MemoryMax=')) ? nextWall : written.wallBytes;
+    return {
+        brakeBytes: brakeOut,
+        wallBytes: wallOut,
+        guaranteedBytes: memoryLow ? wanted.guaranteedBytes : 0,
+        swapBytes: wanted.swapBytes,
+        /**
+         * Carried, not refreshed, while the wall stands still (#403).
+         *
+         * The field means «what this session held when these numbers were written»,
+         * and its own comment says so — but returning `hold` on every tick turned
+         * `shrankItself` into «less than on the previous tick», which is a
+         * different and much rarer thing. On a realistic trace after a build
+         * (4000 → 600, then a plateau of ±10 MiB) the counter never once reached
+         * four in fourteen ticks: every plateau tick with a hold one megabyte above
+         * the last reset it. The wall could therefore never come down at all.
+         */
+        holdBytes: properties.some((p) => p.startsWith('MemoryMax=')) ? hold : written.holdBytes,
+        shrinkTicks,
+        properties,
+        lowered: brakeOut < written.brakeBytes,
+    };
+}
+//# sourceMappingURL=session-allocator.js.map