Skip to content

Promote the tape=0 + from-space-scan parse-then-churn check to a CI gate for the layout-state family #7647

Description

@proggeramlug

PERRY_JSON_TAPE=0 + PERRY_GC_FROMSPACE_SCAN=1 over a parse-then-churn workload is now a known-good end-to-end detector for the whole layout-state family. #7643 measured it: with the JSON materialiser's finalize sabotaged to (ptr, /* saw_pointer */ false) it reports dangling=8000 owners=4000 and the binary SIGBUSes; clean it reports dangling=0 and exits 0.

Nothing runs it in CI. #7643's four unit tests cover the enumerator and the relocation invariant workload-free, which is the right primary guard — but they cannot catch a new materialiser path that forgets to finalize at all, because such a path would simply not be in the test.

What the gate must assert — both halves:

  1. dangling=0 in the from-space scan output, and
  2. that a copying minor actually ran (copied_objects > 0).

Half 2 is not optional. This repo has shipped three gates that were green while their subject never executed (PERRY_GC_FORCE_EVACUATE inert for every gc()-driven test, #6942/#6946; the matrix's --pressure knob disabling the path it measured, #7024; a moved= counter summing two collectors, #7025). A parse-then-churn workload that happens not to trigger a copying minor would report dangling=0 and mean nothing.

Also gate PERRY_JSON_TAPE=0 itself. The whole point of #7635's dead end was that the default lazy path materialises records after the last collection. A future default change that routes this workload lazily again would silently return the gate to vacuity — so the gate should assert the parse it is measuring was eager (record count materialised before the churn, or an equivalent observable).

Not required-on-merge until it has one observed green run on main — a new gate has never been green, so promoting it immediately blocks every open PR (CLAUDE.md, "four ways a gate can be unable to fail", corollary).

Context: #7635, #7633, #7643.

Activity

  1. proggeramlug commented on Aug 8, 2026

    @proggeramlug
    ContributorAuthor

    Both unit-level halves have now landed: #7643 (v0.5.1365, enumerator-level) and #7644 (v0.5.1366, quarantine-poison level, two-sided red-control). This issue remains open and wanted — both are unit tests over a hand-planted object, so neither would catch a new materialiser path that forgets to finalize at all. That is precisely what an end-to-end parse-then-churn gate covers, and it is the reason the gate is worth having on top of two green unit suites.

    Add a third assertion to the two already listed: the gate must assert the parse it measured was eager. A future default that routes the workload through the lazy tape again returns the gate to vacuity silently — see the standing rule in #7644.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions