simon/post-scarcity
1
0
Fork 0
Code Issues 2 Pull requests Projects Releases Packages Wiki Activity Actions

First pass at fixing up wiki links in /docs.

Browse source
This commit is contained in:
Simon Brooke 2025-07-06 10:29:55 +01:00
parent cc534255b5
commit a81b8b130a
21 changed files with 61 additions and 52 deletions
Download patch file Download diff file Expand all files Collapse all files

2
docs/Sysout-and-sysin.md
View file

@ -6,7 +6,7 @@ This might, actually, turn out not to be terribly hard, but is potentially horre
If we use paged memory, as many UNIX systems do, then memory pages periodically get written to disk and the sum total of the memory pages on disk represent an image of the state of system memory. The problem with this is that the state of system memory is changing all the time, and if some pages are out of date with respect to others you don't have a consistent image.
However, the most volatile area of memory is at the outer end of [[cons space]], since that is where cons cells are most likely to die and consequently where new cons cells are most likely to be allocated. We could conceivably take advantage of this by maintaining a per-page [[free list]], and preferentially allocating from the currently busiest page. Volatility in [[vector space]] is likely to be significantly lower, but significantly more distributed. However, if we stick to the general rule that objects aren't mutable, volatility happens only by allocating new objects or deallocating old ones. So it may be the case that if we make a practice of flushing vector space pages when that page is written to, and flushing the active cons space pages regularly, we may at any time achieve a consistent memory image on disk even if it misses the last few seconds worth of changes in cons space.
However, the most volatile area of memory is at the outer end of [cons space](Cons-space.html), since that is where cons cells are most likely to die and consequently where new cons cells are most likely to be allocated. We could conceivably take advantage of this by maintaining a per-page [free list](Free-list.html), and preferentially allocating from the currently busiest page. Volatility in [vector space](Vector-space.html) is likely to be significantly lower, but significantly more distributed. However, if we stick to the general rule that objects aren't mutable, volatility happens only by allocating new objects or deallocating old ones. So it may be the case that if we make a practice of flushing vector space pages when that page is written to, and flushing the active cons space pages regularly, we may at any time achieve a consistent memory image on disk even if it misses the last few seconds worth of changes in cons space.
Otherwise it's worth looking at whether we could journal changes between page flushes. This may be reasonably inexpensive.