<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in module_serialize.rs</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>94740588 - Migrate the Wasmtime CLI to `wasmtime::error` (#12295)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/module_serialize.rs#94740588</link>
        <description>Migrate the Wasmtime CLI to `wasmtime::error` (#12295)* Migrate wasmtime-cli to `wasmtime::error`* migrate benches to `wasmtime::error` as well* Remove new usage of anyhow that snuck in

            List of files:
            /wasmtime-44.0.1/tests/all/module_serialize.rs</description>
        <pubDate>Fri, 09 Jan 2026 19:15:48 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>90ac295e - Update Wasmtime to the 2024 Rust Edition (#10806)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/module_serialize.rs#90ac295e</link>
        <description>Update Wasmtime to the 2024 Rust Edition (#10806)* Update Wasmtime to the 2024 Rust EditionNow that our MSRV supports the 2024 edition it&apos;s possible to make thisswitch. This commit moves Wasmtime to the 2024 Edition to keepup-to-date with Rust idioms and access many of the edition featuresexclusive to the 2024 edition.prtest:full* Reformat with the 2024 edition

            List of files:
            /wasmtime-44.0.1/tests/all/module_serialize.rs</description>
        <pubDate>Mon, 19 May 2025 16:40:55 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>073aedab - Enable the `unsafe-op-in-unsafe-fn` lint (#10559)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/module_serialize.rs#073aedab</link>
        <description>Enable the `unsafe-op-in-unsafe-fn` lint (#10559)* Enable the `unsafe-op-in-unsafe-fn` lintThis commit enables the `unsafe-op-in-unsafe-fn` lint in rustc for theentire workspace. This lint will be warn-by-default in the 2024 editionso this is intended to smooth the future migration to the new edition.Many `unsafe` blocks were added in places the lint warned about, withtwo major exceptions. The `wasmtime` and `wasmtime-c-api` crates simplyexpect this lint to fire and effectively disable the lint. They&apos;re toobig at this time to do through this PR. My hope is that one day in thefuture they&apos;ll be migrated, but more realistically that probably won&apos;thappen so these crates just won&apos;t benefit from this lint.* Fix nostd fiber buildprtest:full* Fix build on Windows* Fix asan build

            List of files:
            /wasmtime-44.0.1/tests/all/module_serialize.rs</description>
        <pubDate>Wed, 09 Apr 2025 21:06:59 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>3e406d2e - Add a `wasmtime objdump` subcommand (#10405)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/module_serialize.rs#3e406d2e</link>
        <description>Add a `wasmtime objdump` subcommand (#10405)This commit adds an `objdump` subcommand to the `wasmtime` CLI. Like allother subcommands this can be disabled for a more minimal build of theCLI as well. The purpose of this subcommand is to provide aWasmtime-specific spin on the venerable native `objdump` itself. Notablythis brings Wasmtime-specific knowledge for filtering functions, showingWasmtime metadata, etc.This command is intended to look like `objdump` roughly but also hasconfigurable output with various flags and things that can be printed.For now the main Wasmtime additions are showing the address mapsection, stack map section, and trap section of a `*.cwasm` file.This new subcommand replaces the infrastructure of the `disas` testsuite, and now that test suite uses `wasmtime objdump` to generate testexpectations. Additionally the subcommand replaces the Pulley `objdump`example as a more full-featured objdump that also works natively withPulley.The hope is that if we add more binary metadata in the future (such asunwinding tables) that can be relatively easily added here forexploration as well. Otherwise this is mostly just a developerconvenience for Wasmtime developers as well and hopefully doesn&apos;t costtoo much in maintenance burden.Closes #10336

            List of files:
            /wasmtime-44.0.1/tests/all/module_serialize.rs</description>
        <pubDate>Thu, 20 Mar 2025 19:23:59 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>15b464b6 - Add `Module::deserialize_open_file` (#9571)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/module_serialize.rs#15b464b6</link>
        <description>Add `Module::deserialize_open_file` (#9571)* Add `Module::deserialize_open_file`Add an API to deserialize a `Module` from an already opened file. Thiscan be useful in situations where `wasmtime` is running in a sandboxedenvironment with limited access to the file system. Then another processcan handle opening the files and passing them to `wasmtime`.* windows fix 1prtest:full* windows fix 2* clippy* windows test fix* windows test fix 2* windows prelude and doc comment* windows_sys import in test* typo

            List of files:
            /wasmtime-44.0.1/tests/all/module_serialize.rs</description>
        <pubDate>Mon, 18 Nov 2024 21:03:37 +0000</pubDate>
        <dc:creator>Adam Bratschi-Kaye &lt;adam.bratschikaye@dfinity.org&gt;</dc:creator>
    </item>
<item>
        <title>7a28a5b9 - Remove static/dynamic memories from public docs (#9545)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/module_serialize.rs#7a28a5b9</link>
        <description>Remove static/dynamic memories from public docs (#9545)* Remove static/dynamic memories from public docsThis commit removes the terminology of &quot;static&quot; and &quot;dynamic&quot; memoriesfrom the public-facing documentation of Wasmtime, notably on the`Config` structure and its various configuration settings. The goal ofthis commit is in the same vein as #9543 which is to simplify the memorysettings of Wasmtime for users in this case.This change doesn&apos;t actually have any code changes beyond renames (andhandling now-deprecated CLI options). The goal of this commit is tobasically rewrite how we document the effect of various settings ofWasmtime. Notably:* `Config::static_memory_maximum_size` is now `memory_reservation`.* `Config::static_memory_forced` is now `memory_reservation_is_maximum`.* `Config::dynamic_memory_reserved_for_growth` is now  `memory_reservation_for_growth`.Documentation for all of these options has been rewritten and updated totake into account the removal of &quot;dynamic&quot; and &quot;static&quot; terminology.Additionally more words have been written about the various effects ofeach setting and how things related to wasm features such as index typesizes and custom page sizes.The rewritten documentation is intended to basically already match whatWasmtime does today. I believe that all of these settings are useful inone form or another so none have been dropped but the updateddocumentation is intended to help simplify the mental model for howthey&apos;re processed internally and how they affect allocations and such.* Fix how the setting is flipped* Review comments

            List of files:
            /wasmtime-44.0.1/tests/all/module_serialize.rs</description>
        <pubDate>Tue, 05 Nov 2024 01:05:58 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>9ce3ffe1 - Update some CI dependencies (#7983)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/module_serialize.rs#9ce3ffe1</link>
        <description>Update some CI dependencies (#7983)* Update some CI dependencies* Update to the latest nightly toolchain* Update mdbook* Update QEMU for cross-compiled testing* Update `cargo nextest` for usage with MIRIprtest:full* Remove lots of unnecessary imports* Downgrade qemu as 8.2.1 seems to segfault* Remove more imports* Remove unused winch trait method* Fix warnings about unused trait methods* More unused imports* More unused imports

            List of files:
            /wasmtime-44.0.1/tests/all/module_serialize.rs</description>
        <pubDate>Thu, 22 Feb 2024 23:54:03 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>137c6f6d - Add an API to detect precompiled modules/components (#6832)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/module_serialize.rs#137c6f6d</link>
        <description>Add an API to detect precompiled modules/components (#6832)This commit adds a new `Engine::detect_precompiled` API to inspect somebytes and determine if they look like a precompiled artifact of either acore wasm module or component. This is something I&apos;ll be using soon inan upcoming refactor of the Wasmtime CLI to support components, but it&apos;ssomething we&apos;ve also talked about before which can be useful for systemsstoring both precompiled modules and components.Implementation-wise this looks at the ELF header of the input anddetermines if it&apos;s got all the right flags that Wasmtime sets for thevarious bits and bobs of our object format.

            List of files:
            /wasmtime-44.0.1/tests/all/module_serialize.rs</description>
        <pubDate>Thu, 10 Aug 2023 20:14:46 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>c0bb341d - Run some tests in MIRI on CI (#6332)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/module_serialize.rs#c0bb341d</link>
        <description>Run some tests in MIRI on CI (#6332)* Run some tests in MIRI on CIThis commit is an implementation of getting at least chunks of Wasmtimeto run in MIRI on CI. The full test suite is not possible to run in MIRIbecause MIRI cannot run Cranelift-produced code at runtime (aka itdoesn&apos;t support JITs). Running MIRI, however, is still quite valuable ifwe can manage it because it would have trivially detectedGHSA-ch89-5g45-qwc7, our most recent security advisory. The goal of thisPR is to select a subset of the test suite to execute in CI under MIRIand boost our confidence in the copious amount of `unsafe` code inWasmtime&apos;s runtime.Under MIRI&apos;s default settings, which is to use the [StackedBorrows][stacked] model, much of the code in `Instance` and `VMContext`is considered invalid. Under the optional [Tree Borrows][tree] model,however, this same code is accepted. After some [extremely helpfuldiscussion][discuss] on the Rust Zulip my current conclusion is thatwhat we&apos;re doing is not fundamentally un-sound but we need to model itin a different way. This PR, however, uses the Tree Borrows model forMIRI to get something onto CI sooner rather than later, and I hope tofollow this up with something that passed Stacked Borrows. Additionallythat&apos;ll hopefully make this diff smaller and easier to digest.Given all that, the end result of this PR is to get 131 separate unittests executing on CI. These unit tests largely exercise the embeddingAPI where wasm function compilation is not involved. Some tests compilewasm functions but don&apos;t run them, but compiling wasm through Craneliftin MIRI is so slow that it doesn&apos;t seem worth it at this time. This doesmean that there&apos;s a pretty big hole in MIRI&apos;s test coverage, but that&apos;sto be expected as we&apos;re a JIT compiler after all.To get tests working in MIRI this PR uses a number of strategies:* When platform-specific code is involved there&apos;s now `#[cfg(miri)]` for  MIRI&apos;s version. For example there&apos;s a custom-built &quot;mmap&quot; just for  MIRI now. Many of these are simple noops, some are `unimplemented!()`  as they shouldn&apos;t be reached, and some are slightly nontrivial  implementations such as mmaps and trap handling (for native-to-native  function calls).* Many test modules are simply excluded via `#![cfg(not(miri))]` at the  top of the file. This excludes the entire module&apos;s worth of tests from  MIRI. Other modules have `#[cfg_attr(miri, ignore)]` annotations to  ignore tests by default on MIRI. The latter form is used in modules  where some tests work and some don&apos;t. This means that all future test  additions will need to be effectively annotated whether they work in  MIRI or not. My hope though is that there&apos;s enough precedent in the  test suite of what to do to not cause too much burden.* A number of locations are fixed with respect to MIRI&apos;s analysis. For  example `ComponentInstance`, the component equivalent of  `wasmtime_runtime::Instance`, was actually left out from the fix for  the CVE by accident. MIRI dutifully highlighted the issues here and  I&apos;ve fixed them locally. Some locations fixed for MIRI are changed to  something that looks similar but is subtly different. For example  retaining items in a `Store&lt;T&gt;` is now done with a Wasmtime-specific  `StoreBox&lt;T&gt;` type. This is because, with MIRI&apos;s analyses, moving a  `Box&lt;T&gt;` invalidates all pointers derived from this `Box&lt;T&gt;`. We don&apos;t  want these semantics, so we effectively have a custom `Box&lt;T&gt;` to suit  our needs in this regard.* Some default configuration is different under MIRI. For example most  linear memories are dynamic with no guards and no space reserved for  growth. Settings such as parallel compilation are disabled. These are  applied to make MIRI &quot;work by default&quot; in more places ideally. Some  tests which perform N iterations of something perform fewer iterations  on MIRI to not take quite so long.This PR is not intended to be a one-and-done-we-never-look-at-it-againkind of thing. Instead this is intended to lay the groundwork tocontinuously run MIRI in CI to catch any soundness issues. This feels,to me, overdue given the amount of `unsafe` code inside of Wasmtime. Myhope is that over time we can figure out how to run Wasm in MIRI butthat may take quite some time. Regardless this will be adding nontrivialmaintenance work to contributors to Wasmtime. MIRI will be run on CI formerges, MIRI will have test failures when everything else passes,MIRI&apos;s errors will need to be deciphered by those who have probablynever run MIRI before, things like that. Despite all this to me it seemsworth the cost at this time. Just getting this running caught twopossible soundness bugs in the component implementation that could havehad a real-world impact in the future![stacked]: https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md[tree]: https://perso.crans.org/vanille/treebor/[discuss]: https://rust-lang.zulipchat.com/#narrow/stream/269128-miri/topic/Tree.20vs.20Stacked.20Borrows.20.26.20a.20debugging.20question* Update alignment comment

            List of files:
            /wasmtime-44.0.1/tests/all/module_serialize.rs</description>
        <pubDate>Wed, 03 May 2023 21:02:33 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>b0939f66 - Remove explicit `S` type parameters (#5275)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/module_serialize.rs#b0939f66</link>
        <description>Remove explicit `S` type parameters (#5275)* Remove explicit `S` type parametersThis commit removes the explicit `S` type parameter on `Func::typed` and`Instance::get_typed_func`. Historical versions of Rust required thatthis be a type parameter but recent rustcs support a mixture of explicittype parameters and `impl Trait`. This removes, at callsites, asuperfluous `, _` argument which otherwise never needs specification.* Fix mdbook examples

            List of files:
            /wasmtime-44.0.1/tests/all/module_serialize.rs</description>
        <pubDate>Wed, 16 Nov 2022 05:04:26 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>cd53bed8 - Implement AOT compilation for components (#5160)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/module_serialize.rs#cd53bed8</link>
        <description>Implement AOT compilation for components (#5160)* Pull `Module` out of `ModuleTextBuilder`This commit is the first in what will likely be a number towardspreparing for serializing a compiled component to bytes, a precompiledartifact. To that end my rough plan is to merge all of the compiledartifacts for a component into one large object file instead of havinglots of separate object files and lots of separate mmaps to manage. Tothat end I plan on eventually using `ModuleTextBuilder` to build onelarge text section for all core wasm modules and trampolines, meaningthat `ModuleTextBuilder` is no longer specific to one module. I&apos;veextracted out functionality such as function name calculation as well asrelocation resolving (now a closure passed in) in preparation for this.For now this just keeps tests passing, and the trajectory for thisshould become more clear over the following commits.* Remove component-specific object emissionThis commit removes the `ComponentCompiler::emit_obj` function in favorof `Compiler::emit_obj`, now renamed `append_code`. This involvedsignificantly refactoring code emission to take a flat list of functionsinto `append_code` and the caller is responsible for weaving togethervarious &quot;families&quot; of functions and un-weaving them afterwards.* Consolidate ELF parsing in `CodeMemory`This commit moves the ELF file parsing and section iteration from`CompiledModule` into `CodeMemory` so one location keeps track ofsection ranges and such. This is in preparation for sharing much of thiscode with components which needs all the same sections to get trackedbut won&apos;t be using `CompiledModule`. A small side benefit from this isthat the section parsing done in `CodeMemory` and `CompiledModule` is nolonger duplicated.* Remove separately tracked traps in componentsPreviously components would generate an &quot;always trapping&quot; functionand the metadata around which pc was allowed to trap was handledmanually for components. With recent refactorings the Wasmtime-standardtrap section in object files is now being generated for components aswell which means that can be reused instead of custom-tracking thismetadata. This commit removes the manual tracking for the `always_trap`functions and plumbs the necessary bits around to make components lookmore like modules.* Remove a now-unnecessary `Arc` in `Module`Not expected to have any measurable impact on performance, butcomplexity-wise this should make it a bit easier to understand theinternals since there&apos;s no longer any need to store this somewhere elsethan its owner&apos;s location.* Merge compilation artifacts of componentsThis commit is a large refactoring of the component compilation processto produce a single artifact instead of multiple binary artifacts. Thecore wasm compilation process is refactored as well to share as muchcode as necessary with the component compilation process.This method of representing a compiled component necessitated a fewmedium-sized changes internally within Wasmtime:* A new data structure was created, `CodeObject`, which represents  metadata about a single compiled artifact. This is then stored as an  `Arc` within a component and a module. For `Module` this is always  uniquely owned and represents a shuffling around of data from one  owner to another. For a `Component`, however, this is shared amongst  all loaded modules and the top-level component.* The &quot;module registry&quot; which is used for symbolicating backtraces and  for trap information has been updated to account for a single region  of loaded code holding possibly multiple modules. This involved adding  a second-level `BTreeMap` for now. This will likely slow down  instantiation slightly but if it poses an issue in the future this  should be able to be represented with a more clever data structure.This commit additionally solves a number of longstanding issues withcomponents such as compiling only one host-to-wasm trampoline persignature instead of possibly once-per-module. Additionally the`SignatureCollection` registration now happens once-per-componentinstead of once-per-module-within-a-component.* Fix compile errors from prior commits* Support AOT-compiling componentsThis commit adds support for AOT-compiled components in the same manneras `Module`, specifically adding:* `Engine::precompile_component`* `Component::serialize`* `Component::deserialize`* `Component::deserialize_file`Internally the support for components looks quite similar to `Module`.All the prior commits to this made adding the support here(unsurprisingly) easy. Components are represented as a single objectfile as are modules, and the functions for each module are all piledinto the same object file next to each other (as are areas such as datasections). Support was also added here to quickly differentiate compiledcomponents vs compiled modules via the `e_flags` field in the ELFheader.* Prevent serializing exported modules on componentsThe current representation of a module within a component means that theimplementation of `Module::serialize` will not work if the module isexported from a component. The reason for this is that `serialize`doesn&apos;t actually do anything and simply returns the underlying mmap as alist of bytes. The mmap, however, has `.wasmtime.info` describingcomponent metadata as opposed to this module&apos;s metadata. While rewritingthis section could be implemented it&apos;s not so easy to do so and isotherwise seen as not super important of a feature right now anyway.* Fix windows build* Fix an unused function warning* Update crates/environ/src/compilation.rsCo-authored-by: Nick Fitzgerald &lt;fitzgen@gmail.com&gt;Co-authored-by: Nick Fitzgerald &lt;fitzgen@gmail.com&gt;

            List of files:
            /wasmtime-44.0.1/tests/all/module_serialize.rs</description>
        <pubDate>Wed, 02 Nov 2022 15:26:26 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>2f4419cc - Implement runtime checks for compilation settings (#3899)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/module_serialize.rs#2f4419cc</link>
        <description>Implement runtime checks for compilation settings (#3899)* Implement runtime checks for compilation settingsThis commit fills out a few FIXME annotations by implementing run-timechecks that when a `Module` is created it has compatible codegensettings for the current host (as `Module` is proof of &quot;this code canrun&quot;). This is done by implementing new `Engine`-level methods whichvalidate compiler settings. These settings are validated on`Module::new` as well as when loading serialized modules.Settings are split into two categories, one for &quot;shared&quot; top-levelsettings and one for ISA-specific settings. Both categories now haveallow-lists hardcoded into `Engine` which indicate the acceptable valuesfor each setting (if applicable). ISA-specific settings are checked withthe Rust standard library&apos;s `std::is_x86_feature_detected!` macro. Othermacros for other platforms are not stable at this time but can be addedhere if necessary.Closes #3897* Fix fall-through logic to actually be correct* Use a `OnceCell`, not an `AtomicBool`* Fix some broken tests

            List of files:
            /wasmtime-44.0.1/tests/all/module_serialize.rs</description>
        <pubDate>Wed, 09 Mar 2022 15:46:25 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>63b7120a - fix the tests</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/module_serialize.rs#63b7120a</link>
        <description>fix the tests

            List of files:
            /wasmtime-44.0.1/tests/all/module_serialize.rs</description>
        <pubDate>Thu, 02 Sep 2021 16:31:21 +0000</pubDate>
        <dc:creator>Pat Hickey &lt;phickey@fastly.com&gt;</dc:creator>
    </item>
<item>
        <title>9e0c9100 - Add a `Module::deserialize_file` method (#3266)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/module_serialize.rs#9e0c9100</link>
        <description>Add a `Module::deserialize_file` method (#3266)* Add a `Module::deserialize_file` methodThis commit adds a new method to the `wasmtime::Module` type,`deserialize_file`. This is intended to be the same as the `deserialize`method except for the serialized module is present as an on-disk file.This enables Wasmtime to internally use `mmap` to avoid copying bytesaround and generally makes loading a module much faster.A C API is added in this commit as well for various bindings to use thisaccelerated path now as well. Another option perhaps for a Rust-basedAPI is to have an API taking a `File` itself to allow for a custom filedescriptor in one way or another, but for now that&apos;s left for a possiblefuture refactoring if we find a use case.* Fix compat with main - handle readdonly mmap* wip* Try to fix Windows support

            List of files:
            /wasmtime-44.0.1/tests/all/module_serialize.rs</description>
        <pubDate>Tue, 31 Aug 2021 18:05:51 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>c73be1f1 - Use an mmap-friendly serialization format (#3257)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/module_serialize.rs#c73be1f1</link>
        <description>Use an mmap-friendly serialization format (#3257)* Use an mmap-friendly serialization formatThis commit reimplements the main serialization format for Wasmtime&apos;sprecompiled artifacts. Previously they were generally a binary blob of`bincode`-encoded metadata prefixed with some versioning information.The downside of this format, though, is that loading a precompiledartifact required pushing all information through `bincode`. This isinefficient when some data, such as trap/address tables, are rarelyaccessed.The new format added in this commit is one which is designed to be`mmap`-friendly. This means that the relevant parts of the precompiledartifact are already page-aligned for updating permissions of pieceshere and there. Additionally the artifact is optimized so that if datais rarely read then we can delay reading it until necessary.The new artifact format for serialized modules is an ELF file. This isnot a public API guarantee, so it cannot be relied upon. In the meantimethough this is quite useful for exploring precompiled modules withstandard tooling like `objdump`. The ELF file is already constructed aspart of module compilation, and this is the main contents of theserialized artifact.THere is some extra information, though, not encoded in each module&apos;sindividual ELF file such as type information. This information continuesto be `bincode`-encoded, but it&apos;s intended to be much smaller and muchfaster to deserialize. This extra information is appended to the end ofthe ELF file. This means that the original ELF file is still a valid ELFfile, we just get to have extra bits at the end. More information on thenew format can be found in the module docs of the serialization moduleof Wasmtime.Another refatoring implemented as part of this commit is to deserializeand store object files directly in `mmap`-backed storage. This avoidsthe need to copy bytes after the artifact is loaded into memory for eachcompiled module, and in a future commit it opens up the door to avoidingcopying the text section into a `CodeMemory`. For now, though, the mainchange is that copies are not necessary when loading from a precompiledcompilation artifact once the artifact is itself in mmap-based memory.To assist with managing `mmap`-based memory a new `MmapVec` type wasadded to `wasmtime_jit` which acts as a form of `Vec&lt;T&gt;` backed by a`wasmtime_runtime::Mmap`. This type notably supports `drain(..N)` toslice the buffer into disjoint regions that are all separately owned,such as having a separately owned window into one artifact for allobject files contained within.Finally this commit implements a small refactoring in `wasmtime-cache`to use the standard artifact format for cache entries rather than abincode-encoded version. This required some more hooks forserializing/deserializing but otherwise the crate still performs asbefore.* Review comments

            List of files:
            /wasmtime-44.0.1/tests/all/module_serialize.rs</description>
        <pubDate>Mon, 30 Aug 2021 14:19:20 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>895ee2b8 - make Module::deserialize&apos;s version check optional via Config (#2945)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/module_serialize.rs#895ee2b8</link>
        <description>make Module::deserialize&apos;s version check optional via Config (#2945)* make Module::deserialize&apos;s version check optional via ConfigA SerializedModule contains the CARGO_PKG_VERSION string, which ischecked for equality when loading. This is a great guard-rail butsome users may want to disable this check (e.g. so they can implementtheir own versioning scheme)* rename config to deserialize_check_wasmtime_version* add test* fix doc links* fix* thank you rustdoc

            List of files:
            /wasmtime-44.0.1/tests/all/module_serialize.rs</description>
        <pubDate>Fri, 04 Jun 2021 19:18:02 +0000</pubDate>
        <dc:creator>Pat Hickey &lt;phickey@fastly.com&gt;</dc:creator>
    </item>
<item>
        <title>7a1b7cdf - Implement RFC 11: Redesigning Wasmtime&apos;s APIs (#2897)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/module_serialize.rs#7a1b7cdf</link>
        <description>Implement RFC 11: Redesigning Wasmtime&apos;s APIs (#2897)Implement Wasmtime&apos;s new API as designed by RFC 11. This is quite a large commit which has had lots of discussion externally, so for more information it&apos;s best to read the RFC thread and the PR thread.

            List of files:
            /wasmtime-44.0.1/tests/all/module_serialize.rs</description>
        <pubDate>Thu, 03 Jun 2021 14:10:53 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>8384f3a3 - Bring back `Module::deserialize` (#2858)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/module_serialize.rs#8384f3a3</link>
        <description>Bring back `Module::deserialize` (#2858)* Bring back `Module::deserialize`I thought I was being clever suggesting that `Module::deserialize` wasremoved from #2791 by funneling all module constructors into`Module::new`. As our studious fuzzers have found, though, this meansthat `Module::new` is not safe currently to pass arbitrary user-definedinput into. Now one might pretty reasonable expect to be able to dothat, however, being a WebAssembly engine and all. This PR as a resultseparates the `deserialize` part of `Module::new` back into`Module::deserialize`.This means that binary blobs created with `Module::serialize` and`Engine::precompile_module` will need to be passed to`Module::deserialize` to &quot;rehydrate&quot; them back into a `Module`. Thisrestores the property that it should be safe to pass arbitrary input to`Module::new` since it&apos;s always expected to be a wasm module. This alsomeans that fuzzing will no longer attempt to fuzz `Module::deserialize`which isn&apos;t something we want to do anyway.* Fix an example* Mark `Module::deserialize` as `unsafe`

            List of files:
            /wasmtime-44.0.1/tests/all/module_serialize.rs</description>
        <pubDate>Tue, 27 Apr 2021 15:55:12 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>6bec13da - Bump versions: Wasmtime to 0.26.0, Cranelift to 0.73.0.</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/module_serialize.rs#6bec13da</link>
        <description>Bump versions: Wasmtime to 0.26.0, Cranelift to 0.73.0.

            List of files:
            /wasmtime-44.0.1/tests/all/module_serialize.rs</description>
        <pubDate>Mon, 05 Apr 2021 17:27:01 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>d1313b12 - Code review feedback.</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/module_serialize.rs#d1313b12</link>
        <description>Code review feedback.* Move `Module::compile` to `Engine::precompile_module`.* Remove `Module::deserialize` method.* Make `Module::serialize` the same format as `Engine::precompile_module`.* Make `Engine::precompile_module` return a `Vec&lt;u8&gt;`.* Move the remaining serialization-related code to `serialization.rs`.

            List of files:
            /wasmtime-44.0.1/tests/all/module_serialize.rs</description>
        <pubDate>Thu, 01 Apr 2021 06:46:30 +0000</pubDate>
        <dc:creator>Peter Huene &lt;peter@huene.dev&gt;</dc:creator>
    </item>
</channel>
</rss>
