Grind

grind — the OpenLDK progress loop

You are advancing OpenLDK: a JIT compiler and runtime for Java (JDK 25) implemented in Common Lisp (SBCL). It translates Java bytecode to Lisp, compiles that to native code, maps Java classes to CLOS classes, and runs on the real headless OpenJDK 25 runtime libraries (jimage/jrt classpath, field-backed Class metadata, invokedynamic/record/typeSwitch support). The converging goal: run real, unmodified Java programs correctly — up to and including javac itself (the javacl image).

/grind = decide what to work on next, reprioritize the queue so that decision is legible, then do the work to completion. One good increment, committed and closed, beats a half-finished heroic epic. Prefer correctness and demonstrable progress toward running real Java over breadth.

0. Orient (every run)

bd prime            # workflow + memories (if context is stale)
bd ready            # claimable work
bd stats            # open/blocked/in-progress shape
bd memories java    # persistent knowledge (build gotchas, native rules, gate)

Skim the recalled Beads memories — especially the build gotcha (JAVA_HOME) and the regression-baseline notes — before touching anything. Pull the relevant src/*.lisp file on demand for the subsystem you touch; do not read all of src/. The runtime core is large:

• src/openldk.lisp — main entry, class loading, classpath, bytecode→Lisp
• src/native/*.lisp — native JDK method implementations (very large)
• src/global-state.lisp — global state / special vars
• src/monitor.lisp, src/fiber.lisp — monitors, virtual-thread fibers

1. Choose the next task — selection rubric

Score candidates in this order and pick the highest that is tractable now:

1. Correctness first. A bug that produces wrong results (silent miscompiles, wrong values, spurious exceptions, aborts, hangs) outranks any feature or perf work. Wrong answers poison everything built on top.
2. On the critical path to running real Java. Prefer work that lets more real, unmodified Java run correctly on JDK 25 — class loading, reflection, invokedynamic/lambda, records, the javacl/javac self-host path.
3. Serves the engine goal. Bytecode→CLOS fidelity, JIT correctness, native JDK method coverage, monitor/thread/fiber semantics. Value work that makes the engine real, not incidental surface.
4. Tractable and verifiable. A clear done-signal and a way to observe it end-to-end (a Java program that now prints the right value, a test that flips, a gate that ratchets up). Favor a well-scoped bug or a decomposable slice over an open-ended epic.

Deprioritize: cosmetic cleanups, speculative features, anything with no line to running-real-Java, and tracking/rollup epics — don't "work" a rollup; decompose it into a concrete child and do that.

When the top candidate is a large epic, carve off the smallest child that delivers real, verifiable value and do that this run.

2. Anti-rat-hole guardrails

• Time-box the investigation. If after a bounded dig the task reveals itself as an architecture epic (multi-subsystem, no clear done-signal), stop: write findings + a decomposition as Beads, pick a smaller adjacent win, and proceed. Don't sink the session into a bottomless path.
• Chase a done-signal, not a rabbit. Every task needs an observable "it works now" (a Java class that returns the right value, a testsuite test that flips PASS, a gate that ratchets). If you can't state it, you're rat-holing.
• Commit validated increments. Don't stockpile a giant uncommitted change. Land each proven step; the next session/agent benefits.
• A decision that's genuinely the maintainer's (a semantics policy, a big irreversible direction) — surface it briefly and pick the safe default or ask, rather than guessing and building the wrong thing at length.