Stream: git-wasmtime

Topic: wasmtime / PR #957 Pre-generate trampoline functions

Wasmtime GitHub notifications bot (Mar 11 2020 at 20:02):

alexcrichton updated PR #957 from local-trampolines to master:

The wasmtime crate supports calling arbitrary function signatures in
wasm code, and to do this it generates "trampoline functions" which have
a known ABI that then internally convert to a particular signature's ABI
and call it. These trampoline functions are currently generated
on-the-fly and are cached in the global Store structure. This,
however, is suboptimal for a few reasons:

• Due to how code memory is managed each trampoline resides in its own
  64kb allocation of memory. This means if you have N trampolines you're
  using N * 64kb of memory, which is quite a lot of overhead!

• Trampolines are never free'd, even if the referencing module goes
  away. This is similar to #925.

• Trampolines are a source of shared state which prevents Store from
  being easily thread safe.

This commit refactors how trampolines are managed inside of the
wasmtime crate and jit/runtime internals. All trampolines are now
allocated in the same pass of CodeMemory that the main module is
allocated into. A trampoline is generated per-signature in a module as
well, instead of per-function. This cache of trampolines is stored
directly inside of an Instance. Trampolines are stored based on
VMSharedSignatureIndex so they can be looked up from the internals of
the ExportFunction value.

The Func API has been updated with various bits and pieces to ensure
the right trampolines are registered in the right places. Overall this
should ensure that all trampolines necessary are generated up-front
rather than lazily. This allows us to remove the trampoline cache from
the Compiler type, and move one step closer to making Compiler
threadsafe for usage across multiple threads.

Note that as one small caveat the Func::wrap* family of functions
don't need to generate a trampoline at runtime, they actually generate
the trampoline at compile time which gets passed in.

Also in addition to shuffling a lot of code around this fixes one minor
bug found in code_memory.rs, where self.position was loaded before
allocation, but the allocation may push a new chunk which would cause
self.position to be zero instead.

Wasmtime GitHub notifications bot (Mar 11 2020 at 21:36):

sunfishcode submitted PR Review.

Wasmtime GitHub notifications bot (Mar 11 2020 at 21:36):

sunfishcode submitted PR Review.

Wasmtime GitHub notifications bot (Mar 11 2020 at 21:36):

sunfishcode created PR Review Comment:

Here and in the other load implementations, it looks like this is dereferencing the wrong thing.

Wasmtime GitHub notifications bot (Mar 11 2020 at 22:11):

alexcrichton updated PR #957 from local-trampolines to master:

The wasmtime crate supports calling arbitrary function signatures in
wasm code, and to do this it generates "trampoline functions" which have
a known ABI that then internally convert to a particular signature's ABI
and call it. These trampoline functions are currently generated
on-the-fly and are cached in the global Store structure. This,
however, is suboptimal for a few reasons:

• Due to how code memory is managed each trampoline resides in its own
  64kb allocation of memory. This means if you have N trampolines you're
  using N * 64kb of memory, which is quite a lot of overhead!

• Trampolines are never free'd, even if the referencing module goes
  away. This is similar to #925.

• Trampolines are a source of shared state which prevents Store from
  being easily thread safe.

This commit refactors how trampolines are managed inside of the
wasmtime crate and jit/runtime internals. All trampolines are now
allocated in the same pass of CodeMemory that the main module is
allocated into. A trampoline is generated per-signature in a module as
well, instead of per-function. This cache of trampolines is stored
directly inside of an Instance. Trampolines are stored based on
VMSharedSignatureIndex so they can be looked up from the internals of
the ExportFunction value.

The Func API has been updated with various bits and pieces to ensure
the right trampolines are registered in the right places. Overall this
should ensure that all trampolines necessary are generated up-front
rather than lazily. This allows us to remove the trampoline cache from
the Compiler type, and move one step closer to making Compiler
threadsafe for usage across multiple threads.

Note that as one small caveat the Func::wrap* family of functions
don't need to generate a trampoline at runtime, they actually generate
the trampoline at compile time which gets passed in.

Also in addition to shuffling a lot of code around this fixes one minor
bug found in code_memory.rs, where self.position was loaded before
allocation, but the allocation may push a new chunk which would cause
self.position to be zero instead.

Wasmtime GitHub notifications bot (Mar 11 2020 at 22:12):

alexcrichton submitted PR Review.

Wasmtime GitHub notifications bot (Mar 11 2020 at 22:12):

alexcrichton created PR Review Comment:

Oh dear good catch! Made sure to add tests to catch this

Wasmtime GitHub notifications bot (Mar 12 2020 at 15:39):

alexcrichton updated PR #957 from local-trampolines to master:

The wasmtime crate supports calling arbitrary function signatures in
wasm code, and to do this it generates "trampoline functions" which have
a known ABI that then internally convert to a particular signature's ABI
and call it. These trampoline functions are currently generated
on-the-fly and are cached in the global Store structure. This,
however, is suboptimal for a few reasons:

• Due to how code memory is managed each trampoline resides in its own
  64kb allocation of memory. This means if you have N trampolines you're
  using N * 64kb of memory, which is quite a lot of overhead!

• Trampolines are never free'd, even if the referencing module goes
  away. This is similar to #925.

• Trampolines are a source of shared state which prevents Store from
  being easily thread safe.

This commit refactors how trampolines are managed inside of the
wasmtime crate and jit/runtime internals. All trampolines are now
allocated in the same pass of CodeMemory that the main module is
allocated into. A trampoline is generated per-signature in a module as
well, instead of per-function. This cache of trampolines is stored
directly inside of an Instance. Trampolines are stored based on
VMSharedSignatureIndex so they can be looked up from the internals of
the ExportFunction value.

The Func API has been updated with various bits and pieces to ensure
the right trampolines are registered in the right places. Overall this
should ensure that all trampolines necessary are generated up-front
rather than lazily. This allows us to remove the trampoline cache from
the Compiler type, and move one step closer to making Compiler
threadsafe for usage across multiple threads.

Note that as one small caveat the Func::wrap* family of functions
don't need to generate a trampoline at runtime, they actually generate
the trampoline at compile time which gets passed in.

Also in addition to shuffling a lot of code around this fixes one minor
bug found in code_memory.rs, where self.position was loaded before
allocation, but the allocation may push a new chunk which would cause
self.position to be zero instead.

Wasmtime GitHub notifications bot (Mar 12 2020 at 19:16):

alexcrichton updated PR #957 from local-trampolines to master:

The wasmtime crate supports calling arbitrary function signatures in
wasm code, and to do this it generates "trampoline functions" which have
a known ABI that then internally convert to a particular signature's ABI
and call it. These trampoline functions are currently generated
on-the-fly and are cached in the global Store structure. This,
however, is suboptimal for a few reasons:

• Due to how code memory is managed each trampoline resides in its own
  64kb allocation of memory. This means if you have N trampolines you're
  using N * 64kb of memory, which is quite a lot of overhead!

• Trampolines are never free'd, even if the referencing module goes
  away. This is similar to #925.

• Trampolines are a source of shared state which prevents Store from
  being easily thread safe.

This commit refactors how trampolines are managed inside of the
wasmtime crate and jit/runtime internals. All trampolines are now
allocated in the same pass of CodeMemory that the main module is
allocated into. A trampoline is generated per-signature in a module as
well, instead of per-function. This cache of trampolines is stored
directly inside of an Instance. Trampolines are stored based on
VMSharedSignatureIndex so they can be looked up from the internals of
the ExportFunction value.

The Func API has been updated with various bits and pieces to ensure
the right trampolines are registered in the right places. Overall this
should ensure that all trampolines necessary are generated up-front
rather than lazily. This allows us to remove the trampoline cache from
the Compiler type, and move one step closer to making Compiler
threadsafe for usage across multiple threads.

Note that as one small caveat the Func::wrap* family of functions
don't need to generate a trampoline at runtime, they actually generate
the trampoline at compile time which gets passed in.

Also in addition to shuffling a lot of code around this fixes one minor
bug found in code_memory.rs, where self.position was loaded before
allocation, but the allocation may push a new chunk which would cause
self.position to be zero instead.

Wasmtime GitHub notifications bot (Mar 12 2020 at 19:35):

sunfishcode submitted PR Review.

Wasmtime GitHub notifications bot (Mar 12 2020 at 19:41):

alexcrichton updated PR #957 from local-trampolines to master:

The wasmtime crate supports calling arbitrary function signatures in
wasm code, and to do this it generates "trampoline functions" which have
a known ABI that then internally convert to a particular signature's ABI
and call it. These trampoline functions are currently generated
on-the-fly and are cached in the global Store structure. This,
however, is suboptimal for a few reasons:

• Due to how code memory is managed each trampoline resides in its own
  64kb allocation of memory. This means if you have N trampolines you're
  using N * 64kb of memory, which is quite a lot of overhead!

• Trampolines are never free'd, even if the referencing module goes
  away. This is similar to #925.

• Trampolines are a source of shared state which prevents Store from
  being easily thread safe.

This commit refactors how trampolines are managed inside of the
wasmtime crate and jit/runtime internals. All trampolines are now
allocated in the same pass of CodeMemory that the main module is
allocated into. A trampoline is generated per-signature in a module as
well, instead of per-function. This cache of trampolines is stored
directly inside of an Instance. Trampolines are stored based on
VMSharedSignatureIndex so they can be looked up from the internals of
the ExportFunction value.

The Func API has been updated with various bits and pieces to ensure
the right trampolines are registered in the right places. Overall this
should ensure that all trampolines necessary are generated up-front
rather than lazily. This allows us to remove the trampoline cache from
the Compiler type, and move one step closer to making Compiler
threadsafe for usage across multiple threads.

Note that as one small caveat the Func::wrap* family of functions
don't need to generate a trampoline at runtime, they actually generate
the trampoline at compile time which gets passed in.

Also in addition to shuffling a lot of code around this fixes one minor
bug found in code_memory.rs, where self.position was loaded before
allocation, but the allocation may push a new chunk which would cause
self.position to be zero instead.

Wasmtime GitHub notifications bot (Mar 12 2020 at 19:42):

alexcrichton updated PR #957 from local-trampolines to master:

The wasmtime crate supports calling arbitrary function signatures in
wasm code, and to do this it generates "trampoline functions" which have
a known ABI that then internally convert to a particular signature's ABI
and call it. These trampoline functions are currently generated
on-the-fly and are cached in the global Store structure. This,
however, is suboptimal for a few reasons:

• Due to how code memory is managed each trampoline resides in its own
  64kb allocation of memory. This means if you have N trampolines you're
  using N * 64kb of memory, which is quite a lot of overhead!

• Trampolines are never free'd, even if the referencing module goes
  away. This is similar to #925.

• Trampolines are a source of shared state which prevents Store from
  being easily thread safe.

This commit refactors how trampolines are managed inside of the
wasmtime crate and jit/runtime internals. All trampolines are now
allocated in the same pass of CodeMemory that the main module is
allocated into. A trampoline is generated per-signature in a module as
well, instead of per-function. This cache of trampolines is stored
directly inside of an Instance. Trampolines are stored based on
VMSharedSignatureIndex so they can be looked up from the internals of
the ExportFunction value.

The Func API has been updated with various bits and pieces to ensure
the right trampolines are registered in the right places. Overall this
should ensure that all trampolines necessary are generated up-front
rather than lazily. This allows us to remove the trampoline cache from
the Compiler type, and move one step closer to making Compiler
threadsafe for usage across multiple threads.

Note that as one small caveat the Func::wrap* family of functions
don't need to generate a trampoline at runtime, they actually generate
the trampoline at compile time which gets passed in.

Also in addition to shuffling a lot of code around this fixes one minor
bug found in code_memory.rs, where self.position was loaded before
allocation, but the allocation may push a new chunk which would cause
self.position to be zero instead.

Wasmtime GitHub notifications bot (Mar 12 2020 at 20:10):

alexcrichton updated PR #957 from local-trampolines to master:

The wasmtime crate supports calling arbitrary function signatures in
wasm code, and to do this it generates "trampoline functions" which have
a known ABI that then internally convert to a particular signature's ABI
and call it. These trampoline functions are currently generated
on-the-fly and are cached in the global Store structure. This,
however, is suboptimal for a few reasons:

• Due to how code memory is managed each trampoline resides in its own
  64kb allocation of memory. This means if you have N trampolines you're
  using N * 64kb of memory, which is quite a lot of overhead!

• Trampolines are never free'd, even if the referencing module goes
  away. This is similar to #925.

• Trampolines are a source of shared state which prevents Store from
  being easily thread safe.

This commit refactors how trampolines are managed inside of the
wasmtime crate and jit/runtime internals. All trampolines are now
allocated in the same pass of CodeMemory that the main module is
allocated into. A trampoline is generated per-signature in a module as
well, instead of per-function. This cache of trampolines is stored
directly inside of an Instance. Trampolines are stored based on
VMSharedSignatureIndex so they can be looked up from the internals of
the ExportFunction value.

The Func API has been updated with various bits and pieces to ensure
the right trampolines are registered in the right places. Overall this
should ensure that all trampolines necessary are generated up-front
rather than lazily. This allows us to remove the trampoline cache from
the Compiler type, and move one step closer to making Compiler
threadsafe for usage across multiple threads.

Note that as one small caveat the Func::wrap* family of functions
don't need to generate a trampoline at runtime, they actually generate
the trampoline at compile time which gets passed in.

Also in addition to shuffling a lot of code around this fixes one minor
bug found in code_memory.rs, where self.position was loaded before
allocation, but the allocation may push a new chunk which would cause
self.position to be zero instead.

Wasmtime GitHub notifications bot (Mar 12 2020 at 21:17):

alexcrichton merged PR #957.

Last updated: Dec 06 2025 at 06:05 UTC