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

Su Engine: Decoding and encoding runtime state. #489

Merged
merged 40 commits into from
Jul 5, 2019
Merged

Su Engine: Decoding and encoding runtime state. #489

merged 40 commits into from
Jul 5, 2019

Conversation

losfair
Copy link
Contributor

@losfair losfair commented Jun 9, 2019

This PR implements a managed runtime that is able to suspend a running WebAssembly program at arbitrary point in time, decode its machine state (registers and stack) into the corresponding WebAssembly abstract state (call frames, locals and the value stack), and encode the abstract state back into machine state for resuming execution later.

Features enabled by this PR include:

  • Tier (compiler backend) switching at runtime.
  • Debugging with backtraces and local variables.
  • Suspending to disk.
  • Live migration.

The name "Su" corresponds to 「溯」 in Chinese, originating from 「溯洄从之」 in The Book of Songs.

@losfair
Copy link
Contributor Author

losfair commented Jun 26, 2019

bors try

bors bot added a commit that referenced this pull request Jun 26, 2019
@losfair losfair marked this pull request as ready for review June 26, 2019 05:12
@bors
Copy link
Contributor

bors bot commented Jun 26, 2019

try

Build failed

@losfair
Copy link
Contributor Author

losfair commented Jun 26, 2019

bors try

bors bot added a commit that referenced this pull request Jun 26, 2019
@@ -18,6 +18,8 @@ errno = "0.2.4"
libc = "0.2.49"
hex = "0.3.2"
smallvec = "0.6.9"
bincode = "1.1"
colored = "1.8"
Copy link
Contributor

Choose a reason for hiding this comment

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

Should colored be moved to a higher level project like wasmer 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

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

How can we use dependencies in the top level workspace in wasmer-runtime-core?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think some user, like runtime and runtime-core users may not have a need for colored output since the usage is not in a terminal, for these cases could this be moved to a higher level project?

Copy link
Contributor Author

@losfair losfair Jul 4, 2019

Choose a reason for hiding this comment

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

I think we can change this later when there's a need for high modularity. Currently I think it's okay to simulate Rust libstd's behavior on panic (output to stderr), though it might be good to add terminal type detection (need more code and not sure whether we really need that)

match *param {
Location::GPR(x) => {
let content = m.state.register_values[X64Register::GPR(x).to_index().0];
//assert!(content != MachineValue::Undefined);
Copy link
Contributor

Choose a reason for hiding this comment

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

Assertions needed or should they be removed?

Copy link
Contributor

Choose a reason for hiding this comment

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

debug_assert! is also a good choice if you think you don't need it but future changes could cause it to be triggered

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added some comments to explain why this assertion should remain commented.

@bjfish
Copy link
Contributor

bjfish commented Jul 4, 2019

bors try

bors bot added a commit that referenced this pull request Jul 4, 2019
@bors
Copy link
Contributor

bors bot commented Jul 4, 2019

@losfair
Copy link
Contributor Author

losfair commented Jul 5, 2019

bors r+

bors bot added a commit that referenced this pull request Jul 5, 2019
489: Su Engine: Decoding and encoding runtime state. r=losfair a=losfair

This PR implements a managed runtime that is able to suspend a running WebAssembly program at arbitrary point in time, decode its machine state (registers and stack) into the corresponding WebAssembly abstract state (call frames, locals and the value stack), and encode the abstract state back into machine state for resuming execution later.

Features enabled by this PR include:

- Tier (compiler backend) switching at runtime.
- Debugging with backtraces and local variables.
- Suspending to disk.
- Live migration.

The name "Su" corresponds to 「溯」 in Chinese, originating from 「溯洄从之」 in The Book of Songs.

Co-authored-by: losfair <zhy20000919@hotmail.com>
@bors
Copy link
Contributor

bors bot commented Jul 5, 2019

@bors bors bot merged commit a3dcc0e into master Jul 5, 2019
@bors bors bot deleted the feature/osr branch July 5, 2019 02:06
repi added a commit to EmbarkStudios/wasmer that referenced this pull request Sep 15, 2019
When the colored output was originally added in wasmerio#489 and there was a discussion then about that it should ideally be in a higher-level crate rather than in the runtime-core library crate.

I agree with that, users of the library shouldn't be required to bring in the colored crate dependency and ideally also not have stdout/stderr output either, that should be controlled by the application that uses wasmer-runtime-core, not the library.

Disabling stdout/stderr output would be more intrusive but I wanted to at least not have colored output and another crate dependency so this change removes the colored output and the "colored" crate.
bors bot added a commit that referenced this pull request Sep 19, 2019
792: Remove colored CLI output from wasmer-runtime-core lib r=syrusakbary a=repi

When the colored output was originally added in #489 and there was a discussion then about that it should ideally be in a higher-level crate rather than in the runtime-core library crate.

I agree with that, users of the library shouldn't be required to bring in the `colored` crate dependency and ideally also not have stdout/stderr output either, that should be controlled by the application that uses wasmer-runtime-core, not the library.

Disabling stdout/stderr output would be more intrusive but I wanted to at least not have colored output and another crate dependency so this change removes the colored output and the `colored` crate.

`colored` also had quite a few dependencies and, while well used, is not super actively maintained. So this change also removes 6 transitive dependencies of the `colored` crate which is great.

This could potentially be a feature flag instead also, but would be a bit messier.

Co-authored-by: Johan Andersson <repi@repi.se>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants