Skip to content

Refactor where results of compilation are stored#2086

Merged
alexcrichton merged 2 commits into
bytecodealliance:mainfrom
alexcrichton:compile-singular-function
Aug 3, 2020
Merged

Refactor where results of compilation are stored#2086
alexcrichton merged 2 commits into
bytecodealliance:mainfrom
alexcrichton:compile-singular-function

Conversation

@alexcrichton
Copy link
Copy Markdown
Member

This commit refactors the internals of compilation in Wasmtime to change
where results of individual function compilation are stored. Previously
compilation resulted in many maps being returned, and compilation
results generally held all these maps together. This commit instead
switches this to have all metadata stored in a CompiledFunction
instead of having a separate map for each item that can be stored.

The motivation for this is primarily to help out with future
module-linking-related PRs. What exactly "module level" is depends on
how we interpret modules and how many modules are in play, so it's a bit
easier for operations in wasmtime to work at the function level where
possible. This means that we don't have to pass around multiple
different maps and a function index, but instead just one map or just
one entry representing a compiled function.

Additionally this change updates where the parallelism of compilation
happens, pushing it into wasmtime-jit instead of wasmtime-environ.
This is another goal where wasmtime-jit will have more knowledge about
module-level pieces with module linking in play. User-facing-wise this
should be the same in terms of parallel compilation, though.

The ultimate goal of this refactoring is to make it easier for the
results of compilation to actually be a set of wasm modules. This means
we won't be able to have a map-per-metadata where the primary key is the
function index, because there will be many modules within one "object
file".

@alexcrichton
Copy link
Copy Markdown
Member Author

I'm not 100% sure how much this interacts with #2064 as well, but it almost surely causes a merge conflict one way or another.

@github-actions github-actions Bot added cranelift Issues related to the Cranelift code generator wasmtime:api Related to the API of the `wasmtime` crate itself labels Jul 31, 2020
@github-actions
Copy link
Copy Markdown

Subscribe to Label Action

cc @bnjbvr, @peterhuene

Details This issue or pull request has been labeled: "cranelift", "wasmtime:api"

Thus the following users have been cc'd because of the following labels:

  • bnjbvr: cranelift
  • peterhuene: wasmtime:api

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

@alexcrichton alexcrichton force-pushed the compile-singular-function branch from 180111f to d25ebad Compare August 3, 2020 15:17
This commit refactors the internals of compilation in Wasmtime to change
where results of individual function compilation are stored. Previously
compilation resulted in many maps being returned, and compilation
results generally held all these maps together. This commit instead
switches this to have all metadata stored in a `CompiledFunction`
instead of having a separate map for each item that can be stored.

The motivation for this is primarily to help out with future
module-linking-related PRs. What exactly "module level" is depends on
how we interpret modules and how many modules are in play, so it's a bit
easier for operations in wasmtime to work at the function level where
possible. This means that we don't have to pass around multiple
different maps and a function index, but instead just one map or just
one entry representing a compiled function.

Additionally this change updates where the parallelism of compilation
happens, pushing it into `wasmtime-jit` instead of `wasmtime-environ`.
This is another goal where `wasmtime-jit` will have more knowledge about
module-level pieces with module linking in play. User-facing-wise this
should be the same in terms of parallel compilation, though.

The ultimate goal of this refactoring is to make it easier for the
results of compilation to actually be a set of wasm modules. This means
we won't be able to have a map-per-metadata where the primary key is the
function index, because there will be many modules within one "object
file".
@alexcrichton alexcrichton force-pushed the compile-singular-function branch from d25ebad to 4a0adfc Compare August 3, 2020 15:37
Copy link
Copy Markdown
Contributor

@yurydelendik yurydelendik left a comment

Choose a reason for hiding this comment

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

Thank for fixing Compilation::from_buffer and src/obj.js. Looks good, but I think it is important to address the comment below.

Comment thread crates/jit/src/compiler.rs Outdated
Persist a smaller set of fields in `CompilationArtifacts` instead of
trying to clear fields out and dynamically not accessing them.
@alexcrichton alexcrichton force-pushed the compile-singular-function branch from 7b40824 to 47763b9 Compare August 3, 2020 16:34
@alexcrichton alexcrichton merged commit 65eaca3 into bytecodealliance:main Aug 3, 2020
@alexcrichton alexcrichton deleted the compile-singular-function branch August 3, 2020 17:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cranelift Issues related to the Cranelift code generator wasmtime:api Related to the API of the `wasmtime` crate itself

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants