pure/research/experiments/030-app-lifecycle/runs.sh, branch masterVerified execution runtime unifying state, persistence, and replication.
http://git.yeowoo.org/pure/atom?h=master2026-10-04T10:07:55ZSay what apps that change on a running host showed (017 stage 3, research 115)2026-10-04T10:07:55Zeunhhunecpition205@gmail.com2026-10-04T10:07:55Zurn:sha1:52e51e4231f2e119c97826ae6d6e2f2af0da0c58
Changing an app in place keeps a million items' app answering but for
1.12 ms (a host restart: 150 ms; stopping and starting it again from its
store, as first built, 150.4 ms), 171.5 ms when its records change shape
(332 ms). Another app's p99 stays 0.97 times as it was while one changes
every 0.2 s; a host of one app is as it was (TPC-C +0.7%, instructions
at most +0.02%); each module change leaves 19 KB. 030 holds the windows
of both builds, the isolation, the pairs, the counts and the memory.
Measure how long an app changing module cannot answer, against a host restart (030)2026-10-04T09:31:09Zeunhhunecpition205@gmail.com2026-10-04T09:31:09Zurn:sha1:93261d1c157e50f1ed2bbc14cf68f2822553b69c
An app of a million items (a list grown by doubling) or of a thousand, in
a host of apps, its store in RAM: the longest gap between two answered
writes while it changes module on SIGHUP (stopped and started again from
its store, 71e319b), and while the host is restarted. A thousand items:
1.59 ms against 3.05 (median of 20 and 10). A million: 150.64 ms against
149.73 (10 and 5): both are the store read again (pure_app_start, 142
ms), so changing does not answer sooner than restarting.