feat: Write protobufs asynchronously [MR-355] #4792
Conversation
pakhomov-dfinity
changed the title
| assert!(execution_state.wasm_memory.page_map.page_delta_is_empty()); | ||
| assert!(execution_state.stable_memory.page_map.page_delta_is_empty()); |
There was a problem hiding this comment.
These assertions as well as the one for wasm_chunk_store hold because we have flushed pagemaps and stripped page deltas earlier, right?
If the calls of persist_delta() here are redundant before this PR., shall we make the changes in a separate small PR? I am asking because this PR makes quite fundamental changes, and it will make it easier to reason about what are changed by async writing.
| Ok(()) | ||
| } | ||
|
|
||
| fn serialize_canister_to_tip( |
There was a problem hiding this comment.
Now, serialize_canister_to_tip is moved to after creating checkpoint and only contains writing canister pbufs.
However,serialize_snapshot_to_tip still contains writing wasm binaries and persisting page deltas. Shall we treat snapshots in the same way as canisters here, i.e. moving writing wasm binaries before creating checkpoint and changing persisting page deltas to just assertions assuming that they are also redundant?
My other PR #4777 fixes a similar issue about for wasm binaries of canister snapshots.
| Ok(()) | ||
| } | ||
|
|
||
| fn serialize_canister_to_tip( |
There was a problem hiding this comment.
Nit: I think this name (along with serialize_to_tip and serialize_snapshot_to_tip) should be more explicit that it only writes protobufs.
| /// 1) `tip` and `layout` mut have exactly the same set of canisters. | ||
| /// 2) The page deltas must be empty in `tip` | ||
| /// 3) The memory sizes must match. | ||
| fn switch_to_checkpoint( |
There was a problem hiding this comment.
Careful about moving this, Shuo's PR modifies this function, and will very likely go in before your PR. You don't want to undo his fix accidentally.
During checkpointing we serialize protobufs of canisters and snapshots on the critical path, even though we don't need them to continue execution. In this change we serialize them in the background in parallel with execution.
Their values are used to validate that the serialized data matches data in memory (ValidateEq). This step is a background operation.