<?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 vmcontext.rs</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>7e0331c2 - Debugging: refactor stack frame cursor into frame handle abstraction. (#12566)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs#7e0331c2</link>
        <description>Debugging: refactor stack frame cursor into frame handle abstraction. (#12566)* Debugging: refactor stack frame cursor into frame handle abstraction.This addresses some of the issues described #12486: we need the abilityto keep a handle to a stack frame as long as execution is frozen, andkeep multiple of these handles around, alongside the `Store`, withoutany handle directly holding a borrow of the store.The frame handles work by means of an &quot;execution version&quot; scheme: theidea is that whenever any execution resumes in a given store, allhandles to existing frames could be invalidated, but if no suchexecution occurs, all handles should still be valid. A tuple of(globally unique for process lifetime) store ID, and execution versionwithin that store, should be sufficient to uniquely identify anyfrozen-stack period during execution. This accomplishes cheap handleinvalidation without the need to track existing handles.This PR also implements a cache of parsed frame-table data. Previouslythis was lazily parsed by the cursor as it walked up a stack, but withmultiple handles hanging around, and with handles meant to be cheap tohold and clone, and with handles being invalidated eagerly, it makesmuch more sense to persist this parsed metadata at the `Store` level.(It cannot persist at the `Engine` level because PCs are local perstore.)* Re-bless disas tests (offsets in VMStoreContext changed).* Handle invalidation tests.* Review comments, and make API return `Result`s rather than panic&apos;ing on stale handles.* Review feedback.* Doc-comment link fix.* Review feedback.* cfg-gate Activation method to `debug` feature only.* Fix unused-import warning in no-debug cfg.* Fix doc link (again, after rename from latest feedback).

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs</description>
        <pubDate>Wed, 11 Feb 2026 23:43:29 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>fae9e6af - add missing may-block checks for sync-to-sync guest-to-guest calls (#12282)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs#fae9e6af</link>
        <description>add missing may-block checks for sync-to-sync guest-to-guest calls (#12282)* add missing may-block checks for sync-to-sync guest-to-guest callsPreviously, we weren&apos;t updating or checking the may-block status of a taskacross sync-to-sync, guest-to-guest calls, meaning we were allowing blocking incases we shouldn&apos;t have.This fixes that by adding a new `task_may_block` field to `VMComponentContext`,plus code to update it every time we switch threads or do a sync-to-sync,guest-to-guest call.  We use that field as the source of truth about whether ablocking operation is permitted.I&apos;ve updated various tests to match, and Luke has an item on his to-do list toadd sad-path coverage for various cases to the upstream `component-model` testsuite.* address review feedback and fix component_instance_size_limit test* remove `TaskMayBlock` type per review feedback* bless disas tests

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs</description>
        <pubDate>Thu, 08 Jan 2026 22:16:30 +0000</pubDate>
        <dc:creator>Joel Dice &lt;joel.dice@fermyon.com&gt;</dc:creator>
    </item>
<item>
        <title>c2cfaa7a - Update upstream wasm spec test suite submodule (#11926)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs#c2cfaa7a</link>
        <description>Update upstream wasm spec test suite submodule (#11926)* Update upstream wasm spec test suite submoduleJuggle some configuration options here and there to accommodate all ofthe new tests.* Fix wasmtime-fuzzing compile* Fix miri script for table.wast* Fix a miri provenance issue

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs</description>
        <pubDate>Thu, 23 Oct 2025 20:23:07 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>ad56ff98 - Implement unsafe intrinsics for compile-time builtins (#11825)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs#ad56ff98</link>
        <description>Implement unsafe intrinsics for compile-time builtins (#11825)* Implement unsafe intrinsics for compile-time builtinsThis commit adds the extremely unsafe`wasmtime::CodeBuilder::expose_unsafe_intrinsics` method. When enabled, the Wasmbeing compiled is given access to special imports that correspond to direct,unchecked and unsandboxed, native load and store operations. These intrinsicsare intended to be used for implementing fast, inline-able versions of WASIinterfaces that are special-cased to a particular host embedding, for example.Compile-time builtins, as originally described in [theRFC](https://github.com/bytecodealliance/rfcs/pull/43), are basically made up ofthree parts:1. A function inliner2. Unsafe intrinsics3. Component composition to encapsulate the usage of unsafe intrinsics in a safeinterfacePart (1) has been implemented in Wasmtime and Cranelift for a little whilenow (see `wasmtime::Config::compiler_inlining`). This commit is part (2). Afterthis commit lands, part (3) can be done with `wac` and `wasm-compose`, althoughfollow up work is required to make the developer experience nicer and moreintegrated into Wasmtime so that the APIs can look like those proposed in theRFC.* fill out some more docs* fix non component model builds* start filling out the doc example* Factor abi params/returns out; truncate/extend pointers* Compile unsafe intrinsics on winch as well* prtest:full* have the macro define the signature* ignore tests in MIRI because MIRI can&apos;t compile Wasm* juggle pointer provenance in `Store::data[_mut]`* add a test for store data provenance and also fix it* use `VmPtr` for the store data pointer* finish writing unsafe intrinsics example* fix up docs and rules around only accessing data from `T` in a `Store&lt;T&gt;`* Only reserve space for the intrinsics&apos; `VMFuncRef`s if they are in use* use dangling pointers instead of options* Rename `StoreInner::data` to `data_no_provenance` and fix some accesses to use the method accessors* Add comments about the provenance juggling inside `StoreInner::data[_mut]`* only compile intrinsics that are usedTurns out we don&apos;t need to add phases, we already have the info available to dothis.* fix duplicate symbol names

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs</description>
        <pubDate>Fri, 17 Oct 2025 00:01:54 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>5245e1f8 - Remove `AllCallFunc` (#11694)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs#5245e1f8</link>
        <description>Remove `AllCallFunc` (#11694)* Remove `AllCallFunc`And add `FuncKeyKind` and `FuncKeyNamespace` types.Split out from https://github.com/bytecodealliance/wasmtime/pull/11630* fix warning and disriminant gap* add module arg to `Module::new()` calls in tests

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs</description>
        <pubDate>Fri, 12 Sep 2025 23:36:30 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>192f2fcd - Replace setjmp/longjmp usage in Wasmtime (#11592)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs#192f2fcd</link>
        <description>Replace setjmp/longjmp usage in Wasmtime (#11592)Since Wasmtime&apos;s inception it&apos;s used the `setjmp` and `longjmp`functions in C to implement handling of traps. While this solution waseasy to implement, relatively portable, and performant enough, there area number of downsides that have evolved over time to make this anunattractive approach in the long run:* Using `setjmp` fundamentally requires using C because Rust does not  understand a function that returns twice. It&apos;s fundamentally unsound  to invoke `setjmp` in Rust meaning that Wasmtime has forever needed a  C compiler configured and set up to build. This notably means that  `cargo check` cannot check other targets easily.* Using `longjmp` means that Rust function frames are unwound on the  stack without running destructors. This is a dangerous operation of  which we get no protection from the compiler about. Both frames  entering wasm and frames exiting wasm are all skipped. Absolutely  minimizing this has been beneficial for portability to platforms such  as Pulley.* Currently the no_std implementation of Wasmtime requires embedders to  provide `wasmtime_{setjmp,longjmp}` which is a thorn in the side of  what is otherwise a mostly entirely independent implementation of  Wasmtime.* There is a performance floor to using `setjmp` and `longjmp`. Calling  `setjmp` requires using C but Wasmtime is otherwise written in Rust  meaning that there&apos;s a Rust-&gt;C-&gt;Rust-&gt;Wasm boundary which  fundamentally can&apos;t be inlined without cross-language LTO which is  difficult to configure.* With the implementation of the WebAssembly exceptions proposal  Wasmtime now has two means of unwinding the stack. Ideally Wasmtime  would only have one, and the more general one is the method of  exceptions.* Jumping out of a signal handler on Unix is tricky business. While  we&apos;ve made it work it&apos;s generally most robust of the signal handler  simply returns which it now does.With all of that in mind the purpose of this commit is to replace thesetjmp/longjmp mechanism of handling traps with the recently implementedsupport for exceptions in Cranelift. That is intended to resolve all ofthe above points in one swoop.One point in particular though that&apos;s nice about setjmp/longjmp is thatunwinding the stack on a trap is an O(1) operation. For situations suchas stack overflow that&apos;s a particularly nice property to have as we canguarantee embedders that traps are a constant time (albeit somewhatexpensive with signals) operation. Exceptions naively require unwindingthe entire stack, and although frame pointers mean we&apos;re just traversinga linked list I wanted to preserve the O(1) property here nonetheless.To achieve this a solution is implemented where the array-to-wasm(host-to-wasm) trampolines setup state in `VMStoreContext` so looking upthe current trap handler frame is an O(1) operation. Namely the sp/fp/pcvalues for a `Handler` are stored inline.Implementing this feature required supportingrelocations-to-offsets-in-functions which was not previously supportedby Wasmtime. This required Cranelift refactorings such as #11570, #11585,and #11576. This then additionally required some more refactoring inthis commit which was difficult to split out as it otherwise wouldn&apos;t betested.Apart from the relocation-related business much of this change is aboutupdating the platform signal handlers to use exceptions instead oflongjmp to return. For example on Unix this means updating the`ucontext_t` with register values that the handler specifies. Windowsinvolves updating similar contexts, and macOS mach ports ended up notneeding too many changes.In terms of overall performance the relevant benchmark from thisrepository, compared to before this commit, is:    sync/no-hook/core - host-to-wasm - typed - nop			    time:   [10.552 ns 10.561 ns 10.571 ns]			    change: [&#8722;7.5238% &#8722;7.4011% &#8722;7.2786%] (p = 0.00 &lt; 0.05)			    Performance has improved.Closes #3927cc #10923prtest:full

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs</description>
        <pubDate>Mon, 08 Sep 2025 14:33:31 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>a631d20a - cranelift: stack-switching support (#11003)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs#a631d20a</link>
        <description>cranelift: stack-switching support (#11003)* cranelift: stack-switching supportThis initial commit represents the &quot;pr2&quot; base commit withminimal merge conflicts resolved.  Due to OOB conflicts, thiscommit is not functional as-is, but using it as a base inorder to allow for easier reviewing of the delta fromthis commit to what will be used for the PR against upstream.Co-authored-by: Daniel Hillerstr&#246;m &lt;daniel.hillerstrom@ed.ac.uk&gt;Co-authored-by: Paul Osborne &lt;paul.osborne@fastly.com&gt;* cranelift: stack-switching updates pass 1This first set of changes updates the base pr in order tocompiled and pass basic checks (compile, clippy, fmt) withthe biggest part of the change being to eliminate injectionof tracing/assertions in JIT&apos;ed code.* cranelift: stack-switching: restore original visibility for a few func_environ members* cranelift: stack-switching conditional compilationAt this point, the only bit we really branch on is what wedo in order to avoid problems tying into wasmtime_environ.This is basd on the approach and macro used by the gc code forconverting presence/absence of the cranelift feature flag tocranelift compile time.  This is a bit of a half-measure for nowas we still compile most stack-switching code in cranelift, butthis does enough to avoid causing problems with missing definitionsin wasmtime_environ.* cranelift: avoid &quot;as&quot; casts in stack-switchingReplace either with infallible From or fallible, panicingTryFrom alternatives where required.* cranelift: cleanup stack-switching control_effect signaturesAfter removing emission of runtime trace logging and assertions,there were several unused parameters.  Remove those from theControlEffect signatures completely.* cranelift: rename stack-switching VMArray to VMHostArrayThis matches a change to the mirrored runtime type inthe upstream changes.* stack-switching: fix typoCo-authored-by: Daniel Hillerstr&#246;m &lt;daniel.hillerstrom@ed.ac.uk&gt;* stack-switching: used Index impl for get_stack_slot_data* stack-switching: use smallvec over vec in several cases* stack-switching: avoid resumetable naming confusion* stack-switching: cleanup unused params from unchecked_get_continuationThe extra parameters here used to be used for emitting runtimeassertions, but with those gone we just had unused paramsand lifetimes, clean those out.* stack_switching: simplify store_data_entries assertion* stack-switching: simplify translate_table_{grow,fill} control flow* stack-switching: remove translate_resume_throw stubThere&apos;s already a stub elsewhere and this is not called, whenexceptions are added and it is time to revisit, this methodcan be restored.* stack-switching: compute control_context_size based on target triple* stack-switching: VMHostArrayRef updatesRename VMHostArray -&gt; VMHostArrayRefChange impl to compute address with offset upfront rather thanon each load.* stack-switching: move cranelift code to live under func_environThis matches the directory structure for gc and aids in visibilityfor a few members required by stack-switching code in cranelift.* stack-switching: formatting fix* stack-switching: reduce visibility on a few additional items* stack-switching: simplify contobj fatptr con/de-struction* stack-switching: add disas tests to cover new instructions* stack-switching: fix layout of VMContObjIn the course of the various runtime updates, the layout of theruntime VMContObj got switched around.  This resulted in failureswhen doing certain table operations on continuations.This change fixes that layout problem and adds some tests withoffsets to avoid the problem.  Due to the way that we interactwith the VMContObj in cranelift, we don&apos;t use these offsets outsideof the tests.* Fix formatting of merge conflict resolution* cranelift: remove ir::function::get_stack_slot_dataThis method isn&apos;t required as sized_stack_slots is already pub.* stack-switching: reduce visibility of a couple func_environ methods* stack-switching: define VMContObj as two wordsThis change migrates VMContObj and its usages in cranelift and runtimeto work with the VMContObj fat pointer as two words in order to bettertarget different architectures (still gated to x86_64 for now).To support this, a size type was plumbed into the builtins functionsignature types (as is done for component types) that maps tousize.* fixup! stack-switching: define VMContObj as two words* stack-switching: add stub Val::ContRefThis type is not fully complete until continuation/gc integrationis revisited (#10248) but without these changes, test cases arenow failing on panics as we need some representation ofcontinuation references in the runtime Val enumeration.Runtime errors with TODO notes are added for the stubbedcode paths to revisit later.* fixup! stack-switching: add stub Val::ContRef* fixup! stack-switching: add stub Val::ContRef* fixup! stack-switching: define VMContObj as two wordsprtest:full* stack-switching: don&apos;t conflate host and target pointer sizesDisas tests were failing on i686 targeting x86_64 as the size of thehost pointer was leaking into what we were using to do codegenin a few paths.  This patch is a bit of a hack as it seems likeusing a generic &lt;T&gt; for T: *mut u8 (as an example) is a bitquestionable.  To keep things small, I do a hacky typecheck to mappointers to the target pointer size here.* stack-switching: VMHostArray entry sizes based off env PtrSizeRevisiting the previous commit with an approach that should beless brittle.---------Co-authored-by: Frank Emrich &lt;git@emrich.io&gt;Co-authored-by: Daniel Hillerstr&#246;m &lt;daniel.hillerstrom@ed.ac.uk&gt;

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs</description>
        <pubDate>Thu, 04 Sep 2025 21:58:01 +0000</pubDate>
        <dc:creator>Paul Osborne &lt;paul.osborne@fastly.com&gt;</dc:creator>
    </item>
<item>
        <title>2d25f862 - WebAssembly exception-handling support. (#11326)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs#2d25f862</link>
        <description>WebAssembly exception-handling support. (#11326)* WebAssembly exception-handling support.This PR introduces support for the [Wasm exception-handling proposal],which introduces a conventional try/catch mechanism to WebAssembly. ThePR supports modules that use `try_table` to register handlers for alexical scope; and provides `throw` and `throw_ref` that allocate (inthe first case) and throw exception objects.This PR builds on top of the work in #10510 for Cranelift-levelexception support, #10919 for an unwinder, and #11230 for exceptionobjects built on top of GC, in addition a bunch of smaller fix andenabling PRs around those.[Wasm exception-handling proposal]: https://github.com/WebAssembly/exception-handling/prtest:full* Permit UnwindToWasm to have unused fields in Pulley builds (for now).* Resolve miri-caught reborrowing issue.* Ignore exceptions tests in miri for now (Pulley not supported).* Use wasmtime_test on exceptions tests.* Get tests passing on pulley platforms* Add a check to `supports_host` for the generated test and assert  failure also when that is false.* Remove `pulley_unsupported` test as it falls out of `#[wasmtime_test]`* Remove `exceptions_store` helper as it falls out of `#[wasmtime_test]`* Remove miri annotations as they fall out of `#[wasmtime_test]`* Remove dead import* Skip some unsupported tests entirely in `#[wasmtime_test]`If the selected compiler doesn&apos;t support the host at all then there&apos;s noneed to run it. Actually running it could misinterpret `CraneliftNative`as &quot;run with pulley&quot; otherwise, so avoid such false negatives.* Cranelift: dynamic contexts: account for outgoing-args area.---------Co-authored-by: Alex Crichton &lt;alex@alexcrichton.com&gt;

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs</description>
        <pubDate>Thu, 21 Aug 2025 02:55:44 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>c6dddeaf - Minimize lazy allocation of the GC store (#11411)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs#c6dddeaf</link>
        <description>Minimize lazy allocation of the GC store (#11411)* Minimize lazy allocation of the GC storeThis commit is an effort to minimize the number of entrypoints whichmight lazily allocate a GC store. The is currently done through`StoreOpaque::gc_store_mut` but this method is very commonly usedmeaning that there are many many places to audit for lazily allocating aGC store. The reason that this needs an audit is that lazy allocationis an async operation right now that must be on a fiber and is somethingI&apos;m looking to fix as part of #11262.This commit performs a few refactorings to achieve this:* `gc_store_mut` is renamed to `ensure_gc_store`. This is intended to be  an `async` function in the future and clearly demarcates where lazy  allocation of a GC store is occurring.* `require_gc_store{,_mut}` is now added which is a pure accessor of the  GC store with no lazy allocation. Most locations previously using  `gc_store_mut` are updated to use this instead.Documentation is added to store methods to clearly indicate which onesare allocating and which ones should only be called in a context whereallocation should already have happened.* Fix configured build* Relax GC store restrictions in more places* Review comments on documentation* Move `ensure_gc_store` calls during instantiationInstead update `needs_gc_heap` with the tables that are added to amodule and rely on instantiation to create the GC heap.* Shuffle around some code* Fix CI and review comments* Add in a few more i31 cases for externref

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs</description>
        <pubDate>Mon, 11 Aug 2025 20:47:20 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>def5998e - Remove `cranelift_entity::{Signed, Unsigned}` (#11400)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs#def5998e</link>
        <description>Remove `cranelift_entity::{Signed, Unsigned}` (#11400)Use `*::cast_{un,}signed` in the Rust standard library stabilized in1.87.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs</description>
        <pubDate>Thu, 07 Aug 2025 23:44:38 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>35786823 - Deny `unsafe_op_in_unsafe_fn` in `wasmtime::runtime::vm` (#11312)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs#35786823</link>
        <description>Deny `unsafe_op_in_unsafe_fn` in `wasmtime::runtime::vm` (#11312)* Deny `unsafe_op_in_unsafe_fn` in `wasmtime::runtime::vm`Slowly expanding this lint to more of the crate.prtest:full* Fix lints in custom module* Fix some lints with miri* Fix non-VM build* Fix arm windows

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs</description>
        <pubDate>Wed, 23 Jul 2025 21:50:06 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>eaa4632e - Implement exception objects. (#11230)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs#eaa4632e</link>
        <description>Implement exception objects. (#11230)* WIP: Working exception objects* Clean build with gc disabled (`cargo check -p wasmtime --no-default-features --features runtime`).* Review feedback.* Stub out C-API support.* Fix Clippy complaints.* Fix dead-code warning in c-api build.* Actually fix 27-&gt;26 reserved bit rename and test.* Fix exnref doc-test.* fix fuzzing build* fix feature-flagging on Instance::id* Bless disas test diff due to reserved-bits change.* Review feedback.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs</description>
        <pubDate>Tue, 15 Jul 2025 17:15:35 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>4b518271 - Add `#[inline]` to some small functions (#11235)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs#4b518271</link>
        <description>Add `#[inline]` to some small functions (#11235)This adds `#[inline]` to some functions which are otherwise notavailable for cross-crate inlining. These functions started being moreheavily used after historical refactorings such as #10877 so this helpsbenchmarks which access linear memory in host functions, for example.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs</description>
        <pubDate>Mon, 14 Jul 2025 16:21:58 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>1b571864 - Delete `vm::Instance::table_grow` (#11216)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs#1b571864</link>
        <description>Delete `vm::Instance::table_grow` (#11216)This commit is a further inch towards #11179 by removing internalreliance on reading `VMContext` pointers and casting them to `Pin&lt;&amp;mutInstance&gt;` in various contexts. Notably now only a defined table needsto be grown, which simplifies the internals of `vm::Instance` ever soslightly. This is a similar change as #11211 which transitions libcallsto using `DefinedTableIndex` instead of `TableIndex`.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs</description>
        <pubDate>Fri, 11 Jul 2025 15:34:36 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>ab76f64b - Make `vm::Instance::get_defined_memory` safe (#11211)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs#ab76f64b</link>
        <description>Make `vm::Instance::get_defined_memory` safe (#11211)This is a small step forward to making `vm::Instance` safe internally.Notably the `get_defined_memory` helper now returns a safe mutablereference instead of a raw pointer. This is then additionally coupledwith the canonicalization of always working with memories as &quot;instanceplus defined memory index&quot; instead of &quot;instance plus memory index&quot;. Thisenables removing some unsafe `VMContext` to `Instance` conversion aswell. This change, however, required updating libcalls to special-casewhen an imported memory is operated on to load the vmcontext/index inthe libcall itself.This change notably does not update the `memory_init` libcall just yetdue to the fact that the `DataIndex` is relative to the owning instanceeven if the memory is owned by a different instance (e.g. it&apos;simported). Otherwise this chips away at some of the `unsafe` related tomemory/table management in `vm::Instance`.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs</description>
        <pubDate>Thu, 10 Jul 2025 16:18:57 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>838ed2d0 - Enable `allow_attributes_without_reason` (#11195)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs#838ed2d0</link>
        <description>Enable `allow_attributes_without_reason` (#11195)* Enable `allow_attributes_without_reason`This commit enables the `clippy::allow_attributes_without_reason` forthe `wasmtime` crate which previously forcibly allowed it. The reasonthis was allowed was that when the workspace was first migrated theWasmtime crate had too many instances that I was willing to fix. I&apos;venow come back around and tried to fix everything.In short: ideally delete `#[allow]`, otherwise use `#[expect]`,otherwise use `#[allow]`.prtest:full* Adjust some directives* Fix some warnings* Fix stack switching size tests on unix* Don&apos;t have a conditional `Drop` impl* Force `testing_freelist` method to be usedToo lazy to write `#[cfg]`, but not too lazy to write a test.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs</description>
        <pubDate>Mon, 07 Jul 2025 21:52:03 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>421136d0 - generalize async fiber abstraction (#11114)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs#421136d0</link>
        <description>generalize async fiber abstraction (#11114)* generalize async fiber abstractionAs part of the work implementing the new Component Model async ABI in the`wasip3-prototyping` repo, I&apos;ve generalized the `FiberFuture` abstraction in`wasmtime::runtime::store::async_` to support fibers which can either retainexclusive access to the store across suspend points or release it.  The latterallows the store to be used by the `component-model-async` event loop and/orother fibers to run before the original fiber resumes, which is the key toallowing multiple fibers to run concurrently, passing control of the store backand forth.In the case of Pulley, the above generalization means we also need to give eachfiber its own `Interpreter` so that multiple concurrent fibers don&apos;t clobbereach other&apos;s state.Concretely, this moves a lot of the code out of `async_.rs` and into a new`fiber.rs` submodule which will be shared with the `component-model-async`implementation.This also pulls in a new `StoreToken&lt;T&gt;` utility which has been useful in`wasip3-prototyping` to safely convert from a `&amp;mut dyn VMStore` to a`StoreContextMut&lt;&apos;a, T&gt;` when we previously witnessed a conversion in the otherdirection.Note that I&apos;ve added a `&apos;static` bound to the `VMStore` trait, which simplifiesuse of `&amp;mut dyn VMStore`, avoiding thorny lifetime issues.Signed-off-by: Joel Dice &lt;joel.dice@fermyon.com&gt;* address review feedbackSigned-off-by: Joel Dice &lt;joel.dice@fermyon.com&gt;* fix miri-flagged stacked borrow violationAs part of my earlier effort to unify the fiber abstractions in the `wasmtime`crate, I changed a `*mut StoreFiber` field to a `&amp;mut StoreFiber`, not realizingthat it resulted in a mutable alias at runtime and thus undefined behavior.Miri caught it, fortunately.Signed-off-by: Joel Dice &lt;joel.dice@fermyon.com&gt;* remove unneeded `Send` boundsSigned-off-by: Joel Dice &lt;joel.dice@fermyon.com&gt;* address more review feedbackMain changes:- Make `resume_fiber[_raw]` take a `&amp;mut StoreOpaque` parameter to make its unsafe internals easier to reason about, safety-wise.- Panic if `StoreFiber::drop` is called on an in-progress fiber without having called `StoreFiber::dispose` to gracefully end it first.- (Re)introduce `FiberFuture`, which closes over a `&amp;mut StoreOpaque` and uses it to call `StoreFiber::dispose` on drop.This will require a few more changes to make it usable by `concurrent.rs`, butI&apos;ll save those changes for a later PR.Signed-off-by: Joel Dice &lt;joel.dice@fermyon.com&gt;* address more review feedbackSigned-off-by: Joel Dice &lt;joel.dice@fermyon.com&gt;* update `impl Send For StoreFiber` commentSigned-off-by: Joel Dice &lt;joel.dice@fermyon.com&gt;* Remove currently-extraneous `Result&lt;()&gt;` from fibersMay be needed for concurrent bits, but for now not necessary.* Use safe pointers instead of raw pointersIt&apos;s predicted Miri won&apos;t like this, but for now in-repo it&apos;s ok with it.* Fold more responsibility into `resume_fiber_raw`Remove the need for the function entirely and replace it with`resume_fiber`.* Remove channels from async fibersCan use stack-based closures/results to transmit the result instead ofneeding a channel.* Fold `on_fiber_raw` directly into `on_fiber`The `on_fiber` function is small enough it should be possible to do so.* Don&apos;t use `Option` in `FiberFuture`Leave the fiber non-optional at-rest so it&apos;s always available for thedestructor.* Fold `suspend` functions togetherSmall shims, not otherwise public at this time, so remove a layer ofindirection.* Move stack limit management to `FiberResumeState`Helps remove some raw pointers that are held for a long time within`AsyncCx`* add some doc comments to `fiber.rs`Signed-off-by: Joel Dice &lt;joel.dice@fermyon.com&gt;* update `fiber.rs` and friends to match CM async requirementsThis adds a `resolve_or_release` function, which `Instance::resume_fiber` willuse when current `concurrent.rs` stub is replaced by a real implementation.Signed-off-by: Joel Dice &lt;joel.dice@fermyon.com&gt;* fix non-component-model-async build warningsSigned-off-by: Joel Dice &lt;joel.dice@fermyon.com&gt;* make `resume_fiber` private in `fiber.rs`Signed-off-by: Joel Dice &lt;joel.dice@fermyon.com&gt;* Shrink `PollContext` stateMove management of the async guard range elsewhere to the normalsave/restore area.* Refactor `AsyncCx`, reduce `unsafe`* Remove the `AsyncCx` type from Wasmtime as it&apos;s inherently `unsafe` to  use, instead bundle operations directly on a `Store*` reference.* Don&apos;t retain pointers-to-pointers within the roughly-equivalent  `BlockingContext` created in this PR. Instead when a blocking context  is created &quot;take&quot; the metadata from the store to assert exclusive  ownership of the pointers.* Refactor how `&amp;mut Context&lt;&apos;_&gt;` is passed around, namely thread it  through fiber parameters to model resumption as registering a new  context to poll with.* Remove `PollContext` in favor of directly storing a pointer as it&apos;s  now mostly an empty structure.* Minor refactorings to make things more future-refactorable and/or  clear in a few places.* Refactor management of the &quot;current suspend&quot; and &quot;current future  context&quot; pointers. These are now null&apos;d out on resumption and asserted  null on suspension.* Remove the need for a generic `Reset` structure in the fiber bits as  it&apos;s a pretty dangerous structure to have in general.The end result of this refactoring is that all usage of `block_on` isnow safe and additionally many of the internals of the implementationare safer than they were before* Adjust some lint attributes* Make manipulation of `AsyncState` safeNo need for raw pointers with recent refactorings.* Fix dead code warning* More dead code warnings* Cut down on raw pointers in fiber.rs* Move executor save/restore to normal fiber state save/restore* Bikeshed a method name* update comment in make_fiberSigned-off-by: Joel Dice &lt;joel.dice@fermyon.com&gt;* fix machports buildSigned-off-by: Joel Dice &lt;joel.dice@fermyon.com&gt;---------Signed-off-by: Joel Dice &lt;joel.dice@fermyon.com&gt;Co-authored-by: Alex Crichton &lt;alex@alexcrichton.com&gt;

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs</description>
        <pubDate>Thu, 26 Jun 2025 21:52:21 +0000</pubDate>
        <dc:creator>Joel Dice &lt;joel.dice@fermyon.com&gt;</dc:creator>
    </item>
<item>
        <title>078bc37b - Fix another case of Miri unsoundness (#11056)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs#078bc37b</link>
        <description>Fix another case of Miri unsoundness (#11056)This commit fixes another issue we&apos;ve discovered in the wasip3prototyping repository about a code pattern in wasm which Miri flags asun-sound. Specifically what happened was:* Invocation of WebAssembly went through `VMFuncRef::array_call` which  takes a `&amp;self` parameter.* Inside of WebAssembly though a `ref.func` instruction, or anything  else that references the original exported function, will  re-initialize the `VMFuncRef` which writes the `&amp;self` up the stack,  which is not sound.Fixing this required changing the signature of `array_call` from `&amp;self`to `me: NonNull&lt;VMFuncRef&gt;`, and the signature was already `unsafe` sothis is a new unsafe contract for that signature.In fixing this, however, it was discovered that a mistake was madein #10943 where some internal functions for re-initializing a`VMFuncRef` relied on the previous signature of `&amp;mut self` but that PRswitche to `&amp;self`. This PR corrects these signatures to `Pin&lt;&amp;mut Self&gt;`and then plumbs around the necessary changes, notably causing somerefactoring in component-related bits.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs</description>
        <pubDate>Tue, 17 Jun 2025 15:55:45 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>8392736d - Refine `VMArrayCallNative` (#11047)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs#8392736d</link>
        <description>Refine `VMArrayCallNative` (#11047)This commit refines the definition of the `VMArrayCallNative` type whichis the type signature of array-call functions which are used forentering and exiting wasm. The first two parameters of this function arethe callee/caller VMContext values but they are both ascribed as`VMOpaqueContext`. This is because for the `callee` it&apos;s not knownexactly what type the pointer has except within the context of thedefining function, so this value was not changed.For the `caller` parameter though it&apos;s always the case that the valuepassed in is indeed a `VMContext`. This commit reflects this fact in thetype signature and removes a number of now-unnecessary casts.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs</description>
        <pubDate>Mon, 16 Jun 2025 15:07:52 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>7e28c254 - Use `Pin&lt;&amp;mut ComponentInstance&gt;` (#11042)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs#7e28c254</link>
        <description>Use `Pin&lt;&amp;mut ComponentInstance&gt;` (#11042)This commit is the continuation of #10943 for component instances. Theallocation/vmctx infrastructure was additionally refactored to be shared forboth core and component instances since they behave the exact same way anyway.This further enables sharing various methods like `vmctx_plus_offset` which arepretty unsafe internally.Like #10943 this necessitated removal of `Index` implementations because`IndexMut` is not compatible with the returned type being `Pin&lt;&amp;mut T&gt;`so they were replaced by inherent `get` and `get_mut` methods on thecomponent instance id type.Closes #10933

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs</description>
        <pubDate>Sat, 14 Jun 2025 01:32:31 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
</channel>
</rss>
