Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Proposal to rework `MemoryCreator` and remove internal types.

Đang mở
  • Có gì không ổn?
#14,989 3 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@V0ldek đang làm issue này rồi.

Từ ngày 28/10/2026.

  • #15046 của @V0ldek — đang mở

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
rust, wasm
Lĩnh vực
api, backend

Hướng nghiên cứu

Start with the FIXME in crates/wasmtime/src/runtime/vm/memory.rs and review the related public MemoryCreator API, RuntimeMemoryCreator, MemoryCreatorProxy, and DefaultMemoryCreator implementations. The proposal requires a breaking API change and coordination across memory creation paths; done means the public trait and internal implementation use MemoryRequest, with the internal types removed and the stated error handling and request fields resolved.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

wasmtime:api

Building on #14885, I'd like to tackle the other half of the linear memory traits. This is already a FIXME in the memory code:

https://github.com/bytecodealliance/wasmtime/blob/ffff2e2db24a291f02429f123aba1631fa8eea67/crates/wasmtime/src/runtime/vm/memory.rs#L73-L74

Since it involves a breaking public API change I thought I'd first go through an issue before I go into slashing the codebase.

Feature

The change would remove RuntimeMemoryCreator and MemoryCreatorProxy. The DefaultMemoryCreator struct would be implemented wholly in terms of the public MemoryCreator trait.

This requires a breaking change to the MemoryCreator. First, the DefaultMemoryCreator receives reservation_for_growth, which is currently not present on the public trait's new_memory. Second, more minor, the current trait requires to return a Result<_, String> instead of the standard wasmtime error type, so fidelity would be lost as the DefaultMemoryCreator would convert all strongly-typed errors to string.

Benefit

Simplifies the code base, fixes an outstanding FIXME, avoids running into issues similar to #10740 because of a mismatch of how the user can implement the memory backend from the outside and internal-only shortcuts.

Implementation

My proposal would be to change the public API so that new_memory task a single parameter, MemoryRequest. That way things can be added as functions on the type without breaking current implementations. Public accessors on the request would return all things the creator needs to serve the request:

impl<'a> MemoryRequest<'a> {
  pub fn ty(&self) -> MemoryType;
  pub fn minimum(&self) -> usize;
  pub fn maximum(&self) -> Option<usize>;
  pub fn reserved_size_in_bytes(&self) -> Option<usize>;
  pub fn guard_size_in_bytes(&self) -> usize;
}

The return type turns into the standard wasmtime Error. This is not really an issue, a user of wasmtime already has to cope with the wasmtime Error anywhere, I don't think there's any advantage to allowing Result<_, String> as it currently is.

Internally, RuntimeMemoryCreator is gone, as is MemoryCreatorProxy. Config holds an Arc<dyn MemoryCreator> instead. The implementation that creates memory in vm::Memory will construct a MemoryRequest and route it to the creator.

Not all things are exposed publicly, I don't necessarily want to increase the public API surface here. The DefaultMemoryCreator needs MemoryTunables for some of the config as well as ty: &wasmtime_environ::Memory. These are not public types, so I'd keep them on MemoryRequest exposed as pub(crate), but not to the outside.

Alternatives

There's a few things one could consider changing:

  1. The documentation now doesn't mention that, but the custom creator is also used for GC heaps. An implementation might want to serve these differently, because their purpose and access patterns are different, but currently there's no way to distinguish that from the public parameters. A simple pub fn kind(&self) returning a non-exhausting MemoryKind enum with LinearMemory and GcHeap fixes this.
  2. The other parameters are passed via tunables and not exposed. For example, MmapMemory uses reservation_for_growth and guard_before_linear_memory, plus signals_based_traps and memory_init_cow to decide whether to use Mmap or Malloc-backed memory.

I also have one open question: reserved_size_in_bytes is an Option<usize>, but the engine always passes Some, with Some(0) meaning "no reservation". Is there any reason for this? What would be the semantic difference between Some(0) and None? Can we just make it a usize?

Ngôn ngữ chính
Rust
Star
18.8k
Fork
1.9k
Merge trung bình
23 giờ 57 phút
Pull request đã merge (30 ngày)
392

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của bytecodealliance/wasmtime

Tất cả issue của bytecodealliance/wasmtime

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.