feat(core-backend): Add the ability to change backend context#4531
Open
feat(core-backend): Add the ability to change backend context#4531
Conversation
…roach-of-funcs-forbidding # Conflicts: # core-backend/src/funcs.rs
…kend-alternative # Conflicts: # core-backend/src/env.rs # core-backend/src/mock.rs # core-backend/src/runtime.rs # core-processor/src/ext.rs # core/src/env.rs
There was a problem hiding this comment.
Pull Request Overview
This PR adds functionality to change the backend context by updating environment state handling, memory reset logic and benchmark configurations. Key changes include:
- Modifying various Environment::new calls to use a callback function instead of a DispatchKind parameter.
- Introducing a new memory dump structure and related memory dump/set functions in the core and processor modules.
- Refining benchmarks, gas counter traits and context types to support new backend context capabilities.
Reviewed Changes
Copilot reviewed 15 out of 15 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| utils/wasm-gen/src/tests.rs | Updated test setup using the new Environment::new API |
| pallets/gear/src/benchmarking/mod.rs | Replaced DispatchKind with callback-based environment creation |
| core/src/memory.rs | Added PageDump structure and enhanced MemoryError with Default |
| core/src/gas.rs | Added Eq and PartialEq to GasAmount for improved comparisons |
| core/src/code/mod.rs | Introduced the new accessor for stack_end |
| core/src/buffer.rs | Added try_replace method along with a new test case |
| core-processor/src/lib.rs | Added a testing module for processor extensions |
| core-processor/src/ext.rs | Implemented new dump_memory and set_memory functions and updated derives |
| core-processor/src/executor.rs | Updated environment creation and error handling in execute calls |
| core-processor/src/context.rs | Adjusted SystemReservationContext with Eq and PartialEq derives |
| core-processor/Cargo.toml | Updated dependencies/features with optional modules for lazy-pages |
| core-backend/src/lib.rs | Revised Environment::new usage and execute call to support backend context changes |
…kend-alternative # Conflicts: # Cargo.lock # core/src/memory.rs
…kend-alternative # Conflicts: # core-backend/src/env.rs # core-processor/Cargo.toml # core-processor/src/executor.rs # core-processor/src/ext.rs # core/src/memory.rs # utils/wasm-gen/src/tests.rs
…kend-alternative # Conflicts: # pallets/gear/src/benchmarking/mod.rs
…kend-alternative # Conflicts: # Cargo.lock
dispatcher integration
This file contains hidden or 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
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.
Resolves #4449
Sequential Execution Optimization for Ethexe Runtime
Summary
This PR implements sequential execution optimization for the ethexe runtime, enabling WASM environment reuse across consecutive dispatch executions. By caching execution contexts and avoiding redundant lazy pages setup/teardown between dispatches, we achieve significant gas savings.
Problem
Previously, each dispatch execution in ethexe required:
This approach incurs substantial overhead when processing multiple dispatches in sequence, as each dispatch paid the full initialization cost (~700M gas) regardless of whether the previous execution could be reused.
Solution
The optimization introduces:
Benchmark Results
Benchmarks comparing gas consumption between this branch and master when processing multiple dispatches (using demo-fungible-token workload with init + mint operations):
Gas Consumption Comparison
Gas per Dispatch Analysis
Execution Time Comparison
Key Observations
Why This Matters
Master's gas consumption scales linearly at ~700M gas per dispatch (full init + execution each time).
This branch's gas consumption is sub-linear:
At 100 dispatches, this means: