Comments (7)
Outstanding, I hope you've had a wonderful Easter weekend! I got the memo last week that I'm going to be laid off, so I'll sort out my dayjob situation first. But after that, I'll whip up a prototype of this. Thanks!
I am sorry to hear about your job situation and wish you all the best to sort it out. Feel free to re-open when you are ready again.
from wasmi.
Hi @mamidon ,
thank you for the feature request.
Wasmi currently supports resumable functions to a limited extend when used as library. It should be possible to support fuel metering for resumable functions in Wasmi in order to make it possible to use fuel as a kind of ticker and refuel the process continuously.
Would this satisfy your use case?
I am very willing to add this feature or accept contributions that do so as long as it does not regress performance of Wasmi in any way significantly.
I am hesistant to add this functionality to the Wasmi CLI though since that would require to come up with binary formats and (de)serialisation support which is hard to get right and a huge amount of work imo.
from wasmi.
Howdy @Robbepop,
I have no particular requests for Wasmi's CLI, the above was just an example of what would be possible.
My only requirement (spec wise, obviously this is your project!) is the ability to serialize state between calls. This implies storing all abstract WebAssembly state (Store, Instance memory, etc) plus enough Wasmi specific state to rehydrate. Supporting resumable functions 'just' means more state to persist & restore.
Using the library as an example, loosely this might look like:
let engine = Engine::default();
let module = Module::new(&engine, &wat::parse_str(...)?)?;
let mut store = Store::new(&engine, 42);
let mut linker = <Linker<HostState>>::new(&engine);
configure_imports(&mut linker);
let instance = linker
.rehydrate("some_file.bin", &module)?; // do not call start!
rehydrate
cracks open a Wasmi specific file, restores relevant state into the Store, and instantiates the WASM instance (skipping most WASM startup logic, this should be transparent to the instance), restores linear memory seamlessly.
You're correct that figuring out exactly what all this state is & how to serialize it is a heavy lift. I'd be happy to work out a detailed design (including what supporting resumable functions requires) and with your sign off, subsequently contribute the implementation.
WRT preformance regressions, I don't think this should be a problem -- serializing & deserializing should happen out of band to WASM execution, although I'm not so certain that support for resumable functions won't require runtime book keeping.
from wasmi.
Okay, I see the difference is that resumable functions only persist state of a single execution and what you want is to persist the state of an entire Wasm instance.
This is going to be a huge amount of work from what I can tell due to the aforementioned work items.
Also this is probably not going to support resumable functions as to not introduce inefficiencies in the executor. Also I think it is fine not to support resumable function calls as a resumable function call is simply one that was stopped but all of its altered state has been written down when it did. And this state is what we capture. Maybe it is possible to support resumable functions without introducing performance regressions.
At this point though I would not want to promise you to merge any of that. So in the worst case you'd end up with a fork of Wasmi that supports hibernatable Wasm instances and I am sure it would work. In the best case the work is great, docs are fine, it does not introduce perf regressions and we find it useful enough for the greater community to merge it to Wasmi.
Currently Wasmi master
is in beta phase and I do not want to introduce any major features at the moment and just focus on bug fixes and stabilizations until the beta phase is over which should hopefully happen soon(TM).
So under these conditions feel free to do the work and let's see where this is heading. :)
from wasmi.
Outstanding, I hope you've had a wonderful Easter weekend! I got the memo last week that I'm going to be laid off, so I'll sort out my
from wasmi.
Don't worry, I've already got a few interview loops going. I'm just a stickler for remote, and refused to return to office lol.
from wasmi.
'Right, I'm back on this. I think I've got a reasonable approach, from the POV of WASM standards.
Persisting a WASM Instance, between function calls -- no state on the implicit stack, is equivalent to taking the module definition and changing it as follows:
- remove any imported memory segment definition
- remove any original passive or active data segments
- remove any original element segments
- any dirty memory pages are replaced with active data segments
- export a memory with required size characteristics
- add an elemns segment which holds entries for any runtime items, e.g. tables
I think that's about it.
Roughly, the public API in WASMI might look like:
- Add
to_module(&self)
onInstance
.. I think I can do this without requiring a reference to the originalModule
- Add
to_segments(&self)
onModule
Actually persisting the module to disk is left as an exercise to the reader, but it should be straightforward to create a fully valid WASM file with all the segments, or one which doesn't have redundant data (like code) if you have the original module file.
from wasmi.
Related Issues (20)
- Create C bindings for Wasmi
- Simplification: Rewrite `iNN.sub` with immediate to new `iNN.add` variant
- Restore CI benchmarks HOT 1
- Wasmi versions `0.32.0-beta.6` cannot run `ffmpeg.wasm` correctly HOT 20
- Update `wasmi_wasi` WASI implementing dependencies HOT 1
- Optimization: Fuse transitive copies HOT 1
- Add `--verbose` mode to Wasmi CLI HOT 2
- Handle host function calls the same as other instructions in the Wasmi executor HOT 1
- Make it possible to debug and pretty print Wasmi bytecode
- Add Wasmi execution profiling HOT 1
- The URL in the project description is 404 HOT 1
- Optimize `Linker` setup
- Add customizable `wasmi::Engine` limits
- Reconsider proper fuel charging for lazily compiled functions
- Reduce `wasmi::Engine` memory consumption for storing function artifacts HOT 3
- Try to put the Wasmi engine internals into its own crate
- Wasmi v0.32 stable release preparations
- Wasmi `v0.32.0-beta.13` seems to have broken linking HOT 13
- CLI: cannot find definition for imported function HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wasmi.