Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for persistent state in separate virtual memory #2321

Merged
merged 1 commit into from
Feb 28, 2024

Conversation

frederikrothenberger
Copy link
Member

@frederikrothenberger frederikrothenberger commented Feb 28, 2024

This PR adds support for the storage layout v9 which keeps the persistent state in a separate virtual memory.
The PR does not include any migration. Existing II installations will keep layout v8.

This PR adds support for the storage layout `v9` which keeps the
persistent state in a separate virtual memory.
The PR does _not_ include any migration. Existing II installations will
keep layout `v8`.
@@ -145,7 +146,7 @@ pub const MAX_ENTRIES: u64 = (MAX_MANAGED_WASM_PAGES - BUCKET_SIZE_IN_PAGES as u

pub type Salt = [u8; 32];

type ArchiveBufferMemory<M> = RestrictedMemory<VirtualMemory<RestrictedMemory<M>>>;
type SingleBucketMemory<M> = RestrictedMemory<VirtualMemory<RestrictedMemory<M>>>;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be cleaner to wrap the underlying memory such that:

  • the memory is guaranteed to be limited to a single bucket
  • the memory cannot be written to

However, I'll do this in a separate PR.

Copy link
Collaborator

@przydatek przydatek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

ii_canister
}

fn ii_canisters_under_test(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A nice improvement! 🎉

@@ -29,16 +29,16 @@ fn should_report_max_number_of_entries_for_256gb() {
}

#[test]
fn should_serialize_header_v8() {
fn should_serialize_header_v9() {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: shouldn't we still keep the test for v8? (i.e. add a new one for v9)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

New storage is now automatically initialized in v9. The ability to initialize v8 is removed.

Compatibility with existing v8 storage is tested in the (unchanged) should_recover_header_from_memory_v8 test.

@frederikrothenberger frederikrothenberger added this pull request to the merge queue Feb 28, 2024
Merged via the queue into main with commit a22e5ec Feb 28, 2024
63 checks passed
@frederikrothenberger frederikrothenberger deleted the frederik/move-config branch February 28, 2024 16:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants