Stream: git-wasmtime

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


view this post on Zulip 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:

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.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 11 2020 at 21:36):

sunfishcode submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 11 2020 at 21:36):

sunfishcode submitted PR Review.

view this post on Zulip 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.

view this post on Zulip 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:

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.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 11 2020 at 22:12):

alexcrichton submitted PR Review.

view this post on Zulip 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

view this post on Zulip 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:

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.

view this post on Zulip 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:

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.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 12 2020 at 19:35):

sunfishcode submitted PR Review.

view this post on Zulip 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:

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.

view this post on Zulip 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:

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.

view this post on Zulip 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:

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.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 12 2020 at 21:17):

alexcrichton merged PR #957.


Last updated: Dec 23 2024 at 12:05 UTC