# GPU-Owned Body Lifecycles

A compact dialogue on GPU-side removal, compaction, appending, overflow, synchronization, and ping-pong buffers.

Generated from `gpu-prog/lessons/0005-no-holes-in-the-horde.md`.

## Transcript

**Host:** The goal is a GPU-owned lifecycle: start with four bodies, remove one, append three, and finish with six live bodies packed into indices zero through five.

**Learner:** So the invariant is that live bodies fill exactly zero up to active count, with no holes, while everything from active count to capacity is spare?

**Host:** Exactly. Five dispatches run in order: reset, remove, compact, append, finish. A barrier separates each pair because every later phase consumes an earlier write.

**Learner:** And the two body buffers avoid trouble during compaction: read the source, write the destination, then swap their roles instead of copying back?

**Host:** Right. Each survivor or birth reserves a slot with atomicAdd on next count. Reservations are unique; slots beyond capacity raise overflow and are never written.

**Learner:** But reservation order depends on which invocation reaches the counter first. That means dense packing is guaranteed, while source order and the losing birth are not?

**Host:** Yes. At capacity six, four minus one plus three gives active six and overflow zero. At capacity five, active is five and overflow one, though any addition may lose.

**Learner:** My takeaway: the CPU submits tiny removal and addition queues, while GPU counters and ping-pong buffers own the lifecycle. Readbacks only prove the result, and indices are not identities.