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

Reuse VM memory across executions #1888

Draft
wants to merge 12 commits into
base: master
Choose a base branch
from
Draft

Conversation

Dentosal
Copy link
Member

@Dentosal Dentosal commented May 8, 2024

Closes #1878. Requires FuelLabs/fuel-vm#732 and a new fuel-vm release.

Introduces a per-thread pool for allocated VM memory instances. Whenever a new VM instance is needed for a tx, the memory is taken from this pool. After the tx has been executed, the memory is reset to an empty state without deallocating, and returned to the pool.

A per-thread pool was chosen to no pass allocations between threads unnecessarily.

Checklist

  • Breaking changes are clearly marked as such in the PR description and changelog (none)
  • New behavior is reflected in tests

Before requesting review

  • I have reviewed the code myself
  • I have created follow-up issues caused by this PR and linked them here

@Dentosal Dentosal added enhancement New feature or request fuel-block-executor labels May 8, 2024
@Dentosal Dentosal self-assigned this May 8, 2024
pub(crate) fn get_vm_memory() -> Memory {
POOL.with(|pool| {
let mut pool = pool.borrow_mut();
pool.pop().unwrap_or_else(Memory::new)
Copy link
Member

@Voxelot Voxelot May 8, 2024

Choose a reason for hiding this comment

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

We should probably have some kind constraint on the max number of items allowed in each pool? Otherwise it should wait if there are none available.

Copy link
Member Author

Choose a reason for hiding this comment

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

We didn't do this earlier, and I don't see why it would make sense to track the items here, instead of just limiting concurrency of the executor itself. That said, keeping a pool per thread is by itself problematic and not useful, as:

  1. The threads are not CPU-pinned anyway
  2. The async runtime might decide to create new threads arbitarily, which would essentially cause a memory leak here

So I' changed the code to not keep separate pools in 5caec42

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Reuse the same instance of the VM for txs in block production and validation
3 participants