Serialize and deserialize compilation artifacts.#2020
Conversation
Subscribe to Label Actioncc @bnjbvr, @peterhuene DetailsThis issue or pull request has been labeled: "cranelift", "wasmtime:api"Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
Subscribe to Label Actioncc @peterhuene DetailsThis 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 |
alexcrichton
left a comment
There was a problem hiding this comment.
Nice!
I think that we'll want to expand the documentation on these functions as well. I'd probably pick one of serialize/deserialize and add a bunch of docs there, referencing these docs from the other function instead of duplication as well.
In terms of documentation contents I think we'll want to document how the bytes are intended to be used, for example they're only usable by one version of the wasmtime crate, they're not intended to be long-lived artifacts. Also we'll probably want a small example in the documentation of serializing/deserializing.
Can you be sure to add some Rust tests as well?
faa08c0 to
ac6c064
Compare
e9b619f to
3b1cb69
Compare
alexcrichton
left a comment
There was a problem hiding this comment.
Sorry missed the updates here but this all looks good to me now!
Fixes #1779
This is final patch in series to allow direct access to the compiled code.
compile_and_serializeAPI function that allows to saveCompilationArtifactsobject in binary format (+target/config fingerprint)Module::deserializeAPI function that allows to read the above data and createModuleobject. Marked unsafe since it does not provide any guarantees for safety of the ingested code.Configs must have the same host triple, codegen flags, andTunables. (Can we ignoreCompilerStrategy?)PR opened for feedback.