-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Disconnects Store
state fields from Compiler
#1761
Conversation
Subscribe to Label Actioncc @peterhuene
This issue or pull request has been labeled: "wasmtime:api"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
1e94ec4
to
c9da8fb
Compare
Subscribe to Label Actioncc @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:
To subscribe or unsubscribe from this label, edit the |
c9da8fb
to
d4e4ade
Compare
b54ba6b
to
2e73c4a
Compare
There was a problem hiding this 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.
Subscribe to Label Actioncc @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:
To subscribe or unsubscribe from this label, edit the |
There was a problem hiding this 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
isSend
andSync
? - 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.
|
||
impl Default for Engine { | ||
fn default() -> Engine { | ||
Engine::new(&Config::default()) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
crates/jit/src/instantiate.rs
Outdated
pub fn module_ref(&self) -> &Module { | ||
&self.module | ||
pub fn module_mut(&mut self) -> &mut Module { | ||
Arc::get_mut(&mut self.module).unwrap() |
There was a problem hiding this comment.
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>, |
There was a problem hiding this comment.
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.
Please add a note to the RELEASES.md describing this change 😄 |
To make wasmtime more threads friendly, this PR:
CodeMemory
,VMInterrupts
andSignatureRegistry
fromCompiler
CompiledModule
holdsCodeMemory
andGdbJitImageRegistration
Store
keeps track of its JIT codeSend
+Sync