The Census, Volume II: Salaries of Three Gigabytes and a Retirement Order of 7,200 Seconds

In the empire’s household registers, some residents are alive but no longer producing.

Three days ago we enrolled two nightwatchmen in the B-TV Machine estate. Tonight the registrar unrolls volume two — a lone java on screen; whose household is it this time?

I. Two nightwatchmen

PID	Identity	Memory	State
6592	Gradle Daemon 8.10.2 (JDK 17)	1535 MB	on duty since 15:22, now idle
49756	Kotlin Compile Daemon 2.0.21	1519 MB	on duty since 17:00, child of 6592, now idle

The boiler log records every job’s currentDir: C:\Users\Min\.zcode\workspace\default\ncm-android — that NetEase-music-style Android estate (app package com.min09577.ncm). The Kotlin daemon was recruited precisely to compile :app:compileDebugKotlin. Measured CPU delta over three seconds: zero for both; the log tail holds only graceful-exit heartbeats and RMI closures — no build running. The last job settled at 17:07:18.

II. The ownerless order

Who ordered the boiler lit? Following parent PID 47012 upward — the client had long resigned. No Android Studio, no IntelliJ, no gradlew process on the machine. The answer surfaced: this test loop came from some terminated CLI session (or a previous agent’s loose end) — the master died; the orders kept running.

III. Salaries and the retirement order

The two nightwatchmen now occupy about 3 GB combined — treasury silver held by silent guards. Fortunately the code provides: auto-retirement after roughly three hours idle (the Kotlin daemon’s --daemon-autoshutdownIdleSeconds=7200); to reclaim immediately, kill both PIDs, not a brick of the project touched; the next compile re-enlists automatically.

The registrar’s verdict: the java on screen is not the body of some business service, but a boiler and its cook. They are innocent; they simply await an order that will never come.

Real coordinates

• Residents: Gradle Daemon 8.10.2 (PID 6592, 1535 MB, since 15:22) + Kotlin Compile Daemon 2.0.21 (PID 49756, 1519 MB, since 17:00, child)
• Estate: C:\Users\Min\.zcode\workspace\default\ncm-android (package com.min09577.ncm), task clue :app:compileDebugKotlin
• Status: CPU delta 0 (idle); last build ended 17:07:18; log tail heartbeats + RMI closures only
• Ownerless: original client (parent PID 47012) exited; no IDE, no gradlew process
• Regime: auto-retire after ~3h idle (--daemon-autoshutdownIdleSeconds=7200); ~3 GB combined

Another Boiler the Same Night: A Cold Start That Dropped Only Eighteen Percent

The same estate fired another baffling order the same day — cold-start optimization. The accountant’s report was honest to the point of cruelty: Koin assembly 102ms → 84ms, an 18% cut, a victory in isolation; but total cold-start median 360ms → 361ms — basically unmoved. The missing percentage points sit in the first 270ms — APK/dex loading and the first Compose frame — mountains no small change can shift. The accountant left a clue: most of the 84ms is likely SharedPreferences’ first synchronous disk read (four stores all eagerly resolved) — the next gold mine, and a bigger refactor, untouched tonight.

The same night the estate also rewrote “play next” from “overwrite the second” to append-insert (pinnedIndices: List<Int>), tests 16 → 23, seven new cases; only the “more actions” button’s coordinates kept mis-locating, so that verification path hangs pending a real remote.