Stream: git-wasmtime

Topic: wasmtime / issue #11179 Management of tables in Wasmtime ...

Wasmtime GitHub notifications bot (Jul 03 2025 at 20:59):

alexcrichton opened issue #11179:

The current management of crate::runtime::vm::Table is excessively unsafe in the context of crate::runtime::vm::Instance in particular at this time. We should clean this up and make this safer.

Some examples of this pattern are:

• get_table returns *mut Table
• get_table and get_defined_table don't share code
• Helper methods go through unsafe VMContext -> Pin<&mut Instance> casting
• Going from &VMTableDefinition to DefinedTableIndex is not safe
• Table initialization requires unsafely simultaneously borrowing Instance and Table at the same time
• Copying between tables is done with raw pointers
• Only handing out raw pointers forces wasmtime::Table to have excessive unsafe blocks

It may not be possible to remove all of this unsafe, but much of this is just trying to juggle ownership and it should in theory be possible to do better. A rough idea of how to handle this would be to use wasmtime::Table more frequently. This is effectively an "indexed based approach" rather than a pointer-based approach. That won't be a silver bullet due to various borrowing requirements (e.g. accessing imported tables) but might be able to help quite a lot. Regardless I think we can do much better than what we're currently doing today.

Wasmtime GitHub notifications bot (Jul 03 2025 at 20:59):

alexcrichton added the wasmtime:unsafe-code label to Issue #11179.

Wasmtime GitHub notifications bot (Jul 16 2025 at 21:58):

alexcrichton edited issue #11179:

The current management of crate::runtime::vm::Table is excessively unsafe in the context of crate::runtime::vm::Instance in particular at this time. We should clean this up and make this safer.

Some examples of this pattern are:

• [x] get_table returns *mut Table
• [x] get_table and get_defined_table don't share code
• [ ] Helper methods go through unsafe VMContext -> Pin<&mut Instance> casting
• [ ] Going from &VMTableDefinition to DefinedTableIndex is not safe
• [x] Table initialization requires unsafely simultaneously borrowing Instance and Table at the same time
• [x] Copying between tables is done with raw pointers
• [ ] Only handing out raw pointers forces wasmtime::Table to have excessive unsafe blocks

It may not be possible to remove all of this unsafe, but much of this is just trying to juggle ownership and it should in theory be possible to do better. A rough idea of how to handle this would be to use wasmtime::Table more frequently. This is effectively an "indexed based approach" rather than a pointer-based approach. That won't be a silver bullet due to various borrowing requirements (e.g. accessing imported tables) but might be able to help quite a lot. Regardless I think we can do much better than what we're currently doing today.

Wasmtime GitHub notifications bot (Jul 16 2025 at 21:58):

alexcrichton edited issue #11179:

The current management of crate::runtime::vm::Table is excessively unsafe in the context of crate::runtime::vm::Instance in particular at this time. We should clean this up and make this safer.

Some examples of this pattern are:

• [x] get_table returns *mut Table
• [x] get_table and get_defined_table don't share code
• [ ] Helper methods go through unsafe VMContext -> Pin<&mut Instance> casting
• [x] Going from &VMTableDefinition to DefinedTableIndex is not safe
• [x] Table initialization requires unsafely simultaneously borrowing Instance and Table at the same time
• [x] Copying between tables is done with raw pointers
• [ ] Only handing out raw pointers forces wasmtime::Table to have excessive unsafe blocks

It may not be possible to remove all of this unsafe, but much of this is just trying to juggle ownership and it should in theory be possible to do better. A rough idea of how to handle this would be to use wasmtime::Table more frequently. This is effectively an "indexed based approach" rather than a pointer-based approach. That won't be a silver bullet due to various borrowing requirements (e.g. accessing imported tables) but might be able to help quite a lot. Regardless I think we can do much better than what we're currently doing today.

Wasmtime GitHub notifications bot (Jul 16 2025 at 21:58):

alexcrichton edited issue #11179:

The current management of crate::runtime::vm::Table is excessively unsafe in the context of crate::runtime::vm::Instance in particular at this time. We should clean this up and make this safer.

Some examples of this pattern are:

• [x] get_table returns *mut Table
• [x] get_table and get_defined_table don't share code
• [x] Helper methods go through unsafe VMContext -> Pin<&mut Instance> casting
• [x] Going from &VMTableDefinition to DefinedTableIndex is not safe
• [x] Table initialization requires unsafely simultaneously borrowing Instance and Table at the same time
• [x] Copying between tables is done with raw pointers
• [ ] Only handing out raw pointers forces wasmtime::Table to have excessive unsafe blocks

It may not be possible to remove all of this unsafe, but much of this is just trying to juggle ownership and it should in theory be possible to do better. A rough idea of how to handle this would be to use wasmtime::Table more frequently. This is effectively an "indexed based approach" rather than a pointer-based approach. That won't be a silver bullet due to various borrowing requirements (e.g. accessing imported tables) but might be able to help quite a lot. Regardless I think we can do much better than what we're currently doing today.

Wasmtime GitHub notifications bot (Jul 16 2025 at 22:12):

alexcrichton edited issue #11179:

The current management of crate::runtime::vm::Table is excessively unsafe in the context of crate::runtime::vm::Instance in particular at this time. We should clean this up and make this safer.

Some examples of this pattern are:

• [x] get_table returns *mut Table
• [x] get_table and get_defined_table don't share code
• [x] Helper methods go through unsafe VMContext -> Pin<&mut Instance> casting
• [x] Going from &VMTableDefinition to DefinedTableIndex is not safe
• [x] Table initialization requires unsafely simultaneously borrowing Instance and Table at the same time
• [x] Copying between tables is done with raw pointers
• [ ] Only handing out raw pointers forces wasmtime::Table to have excessive unsafe blocks (moved to https://github.com/bytecodealliance/wasmtime/issues/11262)

It may not be possible to remove all of this unsafe, but much of this is just trying to juggle ownership and it should in theory be possible to do better. A rough idea of how to handle this would be to use wasmtime::Table more frequently. This is effectively an "indexed based approach" rather than a pointer-based approach. That won't be a silver bullet due to various borrowing requirements (e.g. accessing imported tables) but might be able to help quite a lot. Regardless I think we can do much better than what we're currently doing today.

Wasmtime GitHub notifications bot (Jul 17 2025 at 17:40):

alexcrichton closed issue #11179:

The current management of crate::runtime::vm::Table is excessively unsafe in the context of crate::runtime::vm::Instance in particular at this time. We should clean this up and make this safer.

Some examples of this pattern are:

• [x] get_table returns *mut Table
• [x] get_table and get_defined_table don't share code
• [x] Helper methods go through unsafe VMContext -> Pin<&mut Instance> casting
• [x] Going from &VMTableDefinition to DefinedTableIndex is not safe
• [x] Table initialization requires unsafely simultaneously borrowing Instance and Table at the same time
• [x] Copying between tables is done with raw pointers
• [ ] Only handing out raw pointers forces wasmtime::Table to have excessive unsafe blocks (moved to https://github.com/bytecodealliance/wasmtime/issues/11262)

It may not be possible to remove all of this unsafe, but much of this is just trying to juggle ownership and it should in theory be possible to do better. A rough idea of how to handle this would be to use wasmtime::Table more frequently. This is effectively an "indexed based approach" rather than a pointer-based approach. That won't be a silver bullet due to various borrowing requirements (e.g. accessing imported tables) but might be able to help quite a lot. Regardless I think we can do much better than what we're currently doing today.

Last updated: Dec 06 2025 at 07:03 UTC