Release vere-v2.10 to live #474
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ported from urbit/urbit#6108
See vere#405. This implements a "roll-your-own swapfile", where we designate a file (.urb/ephemeral.bin) to file-back any parts of the loom which are not backed by the snapshot. These are pages in the contiguous free space, and pages that have been dirtied since the last snapshot. With these changes, you should be able to safely reduce the allotted memory to a VM running a machine without relying on separate swap space. The main disadvantages to this approach are: - ephemeral.bin is large (the size of the loom). We could delete it on graceful shutdown, or we could make it a sparse file. - _ce_flaw_protect has to copy the contents of dirtied pages twice. I'm skeptical that this introduces significant slowness, but it could. It may be reasonable to put this behavior behind a flag simply because of the increased disk requirements.
This reverts commit 47ba262.
Co-authored-by: Jake Miller <jraydermiller@gmail.com>
per review comments
This PR is the simplest available fix for #451.
Resolves #456. Written live for a tutorial with @belisarius222
This PR ports urbit/urbit#6159, fixing a performance problem that plagued previous porting attempts. Fixes #157, supersedes #210 and #413. The poor performance observed in #210 and elsewhere was not due to any issue matching or dispatching jets. It coincided with the switch from hoon %140 to %139, but only incidentally. It was caused by a change to the `+solid` pill generator, which inadvertently broke the structural sharing in the lifecycle sequence (see https://github.com/urbit/urbit/pull/5989/files#diff-2f8df9d079ccb58c0a9a9c46f2f7dbd943dabaa21ba658c839de757bbac999f1L108-L116). The problem was unnoticed because, in normal (ie, king/serf) boot and replay, events are sent over IPC in batches, which had the side effect of recovering the necessary structural sharing. This new replay implementation does not involve IPC, but instead reads and computes events synchronously, in a single process. The issue did not arise until ships booted from pills created with the updated generator were replayed using this new implementation, and that happened to coincide with the release of hoon %139. The absence of structural shared lead to jets being registered with one copy of the kernel, but dispatched from a separate copy, resulting in absurdly expensive equality comparisons. Since both copies were already allocated on the home-road, unification could not be performed. And since the problem manifested during the initial phase (lifecycle sequence) of the boot process, `|meld` could not be used. This PR includes a trivial hack to work around such event logs: the lifecycle sequence is read in an inner road, jammed, and then cue'd, thus recovering structural sharing before any nock computation, jet registration, &c. The solid pill generator should also be fixed, but workarounds will still be needed to account for existing piers. Longer-term, home-road unification should clearly be explored to avoid such fragility.
These are the vere changes that accompany urbit/urbit#6669, see that for a description.
Highly relevant to #410 (I think this behavior should be always-on in the presence of "swap"), but also likely useful as a standalone option for low-memory deployments. This is a draft PR as the behavior is hardcoded, not controlled by command-line arguments.
See #405 This implements a "roll-your-own swapfile", where we designate a file (.urb/ephemeral.bin) to file-back any parts of the loom which are not backed by the snapshot. These are pages in the contiguous free space, and pages that have been dirtied since the last snapshot. With these changes, you should be able to safely reduce the allotted memory to a VM running a machine without relying on separate swap space. The main disadvantages to this approach are: - ephemeral.bin is large (the size of the loom). We could delete it on graceful shutdown, or we could make it a sparse file. - _ce_flaw_protect has to copy the contents of dirtied pages twice. I'm skeptical that this introduces significant slowness, but it could. It may be reasonable to put this behavior behind a flag simply because of the increased disk requirements. I've successfully tested various scenarios in a limited memory environment, but this is not well enough tested to be ready for merging. Main things I've tested (all on a machine with 1GB RAM and no swap): - Boot - Allocate 8 128MB atoms in the dojo in a row, verifying |mass is 1.2GB afterward - Free those atoms, run |pack, recreate them, free them again, |pack again - Restart ship, recreate those atoms, free them, and |pack All of this worked fine on that machine, even though the ephemeral memory usage must have been greater than the RAM on the machine, and there were no swap files. During most of this, the htop-reported "resident memory" for the serf process was around 400-600MB, while the amount of memory "used" overall per `free -h` was under 180-250MB every time I checked. This is consistent with the OS deciding how much of the backing files to keep resident at any given time, while the amount of memory strictly required stays fairly small. Testing on a machine with plenty of memory, I didn't notice any slowdown. On the 1GB machine, it was somewhat slow to allocate the large atoms, but it felt about right considering they must have been written to the backing file. Graceful shutdown was somewhat slow sometimes, presumably when it needed to copy from the ephemeral file to the snapshot.
In testing, I commonly use `=a (bex (bex 29))` as a way to use 128MB of memory. It's been annoying that you can't do 256MB or more in this way, because the +bex jet didn't support it. This PR raises that limit to strictly less than 2GB. This also reduces the ephemeral memory usage of the `+bex` jet on large numbers by half. This was limited to strictly less than 256MB because it used a gmp method to perform the binary exponent. I briefly looked at whether gmp would handle double-length words for the exponent, but decided it was simpler and more efficient anyway to write this jet directly, ie allocate `a+1` bits and set the `a`th bit. This saves one copy of the entire result, and allows it to function up to 2GB minus one. This function would work correctly above this limit, but there are other parts of the system that seem to implicitly assume that atoms cannot be 2GB or larger. The first one I ran into was `mug`, but there may be others; after all, for a long time it was safe to assume nothing could be larger than 2GB because that was the loom size.
These checks were introduced in v2.7, aborting the process if the snapshot metadata indicated that truncation had occurred. But the check as written is unnecessarily strict, and also aborts the process if the snapshot was larger than necessary. This PR prints a warning in that case and otherwise continues.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.