Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disconnects Store state fields from Compiler #1761

Merged
merged 39 commits into from
Jun 2, 2020

Conversation

yurydelendik
Copy link
Contributor

@yurydelendik yurydelendik commented May 26, 2020

To make wasmtime more threads friendly, this PR:

  • Moves CodeMemory, VMInterrupts and SignatureRegistry from Compiler
  • CompiledModule holds CodeMemory and GdbJitImageRegistration
  • Store keeps track of its JIT code
  • Makes "jit_int.rs" stuff Send+Sync
  • Adds the threads example.

@github-actions github-actions bot added the wasmtime:api Related to the API of the `wasmtime` crate itself label May 26, 2020
@yurydelendik yurydelendik requested a review from alexcrichton May 26, 2020 20:00
@github-actions
Copy link

Subscribe to Label Action

cc @peterhuene

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

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

  • peterhuene: wasmtime:api

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

Learn more.

@github-actions github-actions bot added the wasmtime:c-api Issues pertaining to the C API. label May 26, 2020
@github-actions
Copy link

Subscribe to Label Action

cc @peterhuene

This issue or pull request has been labeled: "wasmtime:c-api"

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

  • peterhuene: wasmtime:c-api

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

Learn more.

Copy link
Member

@alexcrichton alexcrichton left a comment

Choose a reason for hiding this comment

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

Nice!

This is looking really promising I think. I've left some various comments about organization below.

Also, would you be up for adding some more tests about using threads? I think it'd be good to try to start adding various tests here and there that try to stress the multithreaded aspects.

crates/jit/src/instantiate.rs Outdated Show resolved Hide resolved
examples/threads.c Show resolved Hide resolved
crates/wasmtime/src/module.rs Outdated Show resolved Hide resolved
crates/runtime/src/instance.rs Outdated Show resolved Hide resolved
crates/wasmtime/src/runtime.rs Outdated Show resolved Hide resolved
crates/wasmtime/src/runtime.rs Outdated Show resolved Hide resolved
crates/wasmtime/src/runtime.rs Show resolved Hide resolved
@yurydelendik yurydelendik marked this pull request as ready for review May 27, 2020 19:37
@yurydelendik yurydelendik requested a review from alexcrichton May 27, 2020 19:37
@github-actions
Copy link

Subscribe to Label Action

cc @fitzgen

This issue or pull request has been labeled: "fuzzing", "wasmtime:docs"

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

  • fitzgen: fuzzing

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

Learn more.

Copy link
Member

@alexcrichton alexcrichton left a comment

Choose a reason for hiding this comment

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

Looking great, thanks! Some other remaining points I can think of:

  • Can the documentation be updated that Module is threadsafe and safe to share across threads?
  • Can a test be specifically added that Module is Send and Sync?
  • I think we may want some form of checks when we instantiate a module into a store. I'm a bit worried about, for example you compile it with one engine that conflicts with configuration within another engine. For example you could compile it in one engine with interrupts disabled, and then instantiate it in another with interrupts enabled, and then interrupts wouldn't work.

crates/c-api/src/instance.rs Outdated Show resolved Hide resolved
crates/c-api/src/module.rs Outdated Show resolved Hide resolved
crates/jit/src/instantiate.rs Outdated Show resolved Hide resolved
crates/runtime/src/jit_int.rs Outdated Show resolved Hide resolved
crates/runtime/src/jit_int.rs Outdated Show resolved Hide resolved
crates/runtime/src/jit_int.rs Outdated Show resolved Hide resolved
crates/runtime/src/jit_int.rs Outdated Show resolved Hide resolved
crates/wasmtime/src/frame_info.rs Outdated Show resolved Hide resolved
crates/wasmtime/src/runtime.rs Outdated Show resolved Hide resolved
crates/wasmtime/src/runtime.rs Outdated Show resolved Hide resolved
crates/wasmtime/src/runtime.rs Outdated Show resolved Hide resolved

impl Default for Engine {
fn default() -> Engine {
Engine::new(&Config::default())
Copy link
Member

Choose a reason for hiding this comment

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

Could Default for Store delegate to this now that it exists?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure how to do it: Engine::new and Store::new have some additional logic that needs to be run.

crates/wasmtime/src/runtime.rs Outdated Show resolved Hide resolved
crates/wasmtime/src/runtime.rs Show resolved Hide resolved
crates/c-api/src/module.rs Outdated Show resolved Hide resolved
crates/runtime/src/jit_int.rs Outdated Show resolved Hide resolved
@yurydelendik yurydelendik requested a review from alexcrichton June 1, 2020 23:27
Copy link
Member

@alexcrichton alexcrichton left a comment

Choose a reason for hiding this comment

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

FWIW this is a relatively major API change for all users since Module::new and Instance::new are changing. I think the Instance::new change is fine to sweep under the rug because it's largely supplanted by Linker, but Module::new is somewhat serious and you can see the effect it has on all the examples here.

The only way I could see of how to improve things is to implement AsRef<Engine> for Store and then take impl AsRef<Engine> in the constructor for Module. That way folks still wouldn't need to deal with Engine in general.

I don't think it's necessary to do that in this PR, however. I think it's fine to leave this for a later date if truly necessary.

pub fn module_ref(&self) -> &Module {
&self.module
pub fn module_mut(&mut self) -> &mut Module {
Arc::get_mut(&mut self.module).unwrap()
Copy link
Member

Choose a reason for hiding this comment

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

Instead of embedding the .unwrap() here, could this return Option<&mut Module>? It's only used in one location right now which is fine, but I'd prefer to avoid proliferating users of this API

@@ -40,6 +38,9 @@ pub(crate) struct Instance {
/// The `Module` this `Instance` was instantiated from.
module: Arc<Module>,

/// The module's JIT code (if exists).
code: Arc<dyn Any>,
Copy link
Member

Choose a reason for hiding this comment

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

Long-term it feels weird to have two dyn Any in this Instance, instead ideally we'd just have one Box<dyn Any> and shove everything in there. I don't want to iterate too much on this, it's pretty unimportant at this time. Just something to keep in mind for the future, this is more than ok for now.

@sunfishcode
Copy link
Member

Please add a note to the RELEASES.md describing this change 😄

@yurydelendik yurydelendik merged commit 15c68f2 into bytecodealliance:master Jun 2, 2020
@yurydelendik yurydelendik deleted the mv-sig-registry branch June 2, 2020 18:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fuzzing Issues related to our fuzzing infrastructure wasmtime:api Related to the API of the `wasmtime` crate itself wasmtime:c-api Issues pertaining to the C API. wasmtime:docs Issues related to Wasmtime's documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants