Changes in data.rs

3f530214 - Generalize `VMGcObjectDataMut` for immutable GC object accesses too (#10462)

Tue, 25 Mar 2025 00:38:47 +0000

Generalize `VMGcObjectDataMut` for immutable GC object accesses too (#10462)* Generalize `VMGcObjectDataMut` for immutable GC object accesses tooThis makes it generic over a `T` and then shared+immutable accesses are bound by`T: AsRef<[u8]>` and exclusive+mutable accesses are bound by `T: AsMut<[u8]>`.This allows reusing these accessors in more places in the future, and meansthere are fewer places to bounds check accesses and remember to do little-endianconversion and all that.* Make `VMGcObjectData` a fancy unsized newtype* fix no-gc builds List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/gc/enabled/data.rs

83bf774d - Add the "null" garbage collector (#9484)

Thu, 31 Oct 2024 17:46:17 +0000

Add the "null" garbage collector (#9484)* Add the "null" garbage collectorThe null collector does not actually collect any garbage, it simplybump-allocates until the heap is exhausted, at which point further allocationattempts will fail. It does not require any GC barriers.Users can configure which collector to use via the `wasmtime::Config::collector`method or the `-C collector=drc|null` CLI flag. The `wasmtime::Collector` enumeration,similar to the `wasmtime::Strategy` enumeration but for choosing a collectorrather than a compiler, additionally has a table summarizing the properties andcharacteristics of our current set of collector implementations.Finally, we also run `.wast` tests that exercise GC types under both the DRC andnull collectors. I tried to avoid running tests that are not related to GC underboth configurations just to avoid a combinatorial blow up.* cargo fmt* fix +gc -gc-null -gc-drc build* Fix some warnings in various cargo feature combo builds* Fix some more warnings in certain build configs* Fix unit tests for null GC* Fill in some placeholder comments that I forgot to write* Fix issues where we ask for a GC store when we don't actually need oneWhich was causing test failures, since we no longer return a GC store with adummy heap.* Add fuzzing config support for different collectors* address review feedback* fix cmake tests* Fix test compilation after rebase* Fix GC tests under MIRI List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/gc/enabled/data.rs

818966f3 - Implement the `array.copy` Wasm GC instruction (#9389)

Mon, 07 Oct 2024 19:08:31 +0000

Implement the `array.copy` Wasm GC instruction (#9389)* Implement the `array.copy` Wasm GC instructionThis also involved fixing some `VMGcRef` initialization and GC barrier code forglobals. That in turn involved making global initialization fallible, whichmeant that it needed to be pulled out of `vmctx` initialization and put intoinstance initialization.Co-Authored-By: Alex Crichton * fix compile error due to code moving where a trait method was no longer in scope* use the result of `MaybeUninit::write`---------Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/gc/enabled/data.rs

ec3b2d22 - Implement most `array.*` instructions for the GC proposal (#9326)

Mon, 30 Sep 2024 19:25:35 +0000

Implement most `array.*` instructions for the GC proposal (#9326)* Implement most `array.*` instructions for the GC proposalThis does not implement `array.copy` and `array.init_elem` yet, but implementsall other `array.*` instructions:* `array.new`* `array.new_fixed`* `array.new_default`* `array.new_data`* `array.new_elem`* `array.fill`* `array.init_data`* `array.len`* `array.get`* `array.get_s`* `array.get_u`* `array.set`Note that the initial plumbing for `array.{copy,init_elem}` is in place, but theinstructions themselves are not implemented yet.* Fix no-gc builds* Fix some clippy warnings* cargo fmt* Fix another clippy error* Fix more clippy errors* Remove debug logging* Add array.fill helper* exit scope even on panic List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/gc/enabled/data.rs

c5e04337 - Always keep data inside GC objects in little-endian order (#9320)

Fri, 27 Sep 2024 18:29:00 +0000

Always keep data inside GC objects in little-endian order (#9320)* Always keep data inside GC objects in little-endian orderWe were previously using native-endian on the assumption that it wasn'tobservable to Wasm, but it turns out that assumption isn't true. The`array.[init,new]_data` instructions take a data segment and copy it into anarray. The arrays are not limited to `i8` arrays; they can be any non-referencetype, so the endianness is visible, and Wasm requires little endian.* Use little-endian stores for initializing GC fields as wellNot just reading and writing to already-initialized fields.* Update disas tests List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/gc/enabled/data.rs

128e6b8f - Add constant evaluation support for the `struct.new[_default]` Wasm GC instructions (#9282)

Thu, 19 Sep 2024 18:05:41 +0000

Add constant evaluation support for the `struct.new[_default]` Wasm GC instructions (#9282)* Add constant evaluation support for the `struct.new[_default]` Wasm GC instructions* fix no-gc builds* wrap const evaluation in `AutoAssertNoGc`* add assertions that we access `VMGcRef`s in native-endian* fix an endian mismatch bug between compiled wasm code and host code List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/gc/enabled/data.rs

c4be2d84 - Introduce `wasmtime::ArrayRef` and allocating Wasm GC arrays (#9145)

Tue, 20 Aug 2024 19:34:28 +0000

Introduce `wasmtime::ArrayRef` and allocating Wasm GC arrays (#9145)* Introduce `wasmtime::ArrayRef` and allocating Wasm GC arraysThis commit introduces the `wasmtime::ArrayRef` type and support for allocatingWasm GC arrays from the host. This commit does *not* add support for the`array.new` family of Wasm instructions; guests still cannot allocate Wasm GCobjects yet, but initial support should be pretty straightforward after thiscommit lands.The `ArrayRef` type has everything you expect from other value types in the`wasmtime` crate:* A method to get its type or check whether it matches a given type* An implementation of `WasmTy` so that it can be used with `Func::wrap`-style APIs* The ability to upcast it into an `AnyRef` and to do checked downcasts in the opposite directionThere are, additionally, methods for getting, setting, and enumerating a`ArrayRef`'s elements.Similar to how allocating a Wasm GC struct requires a `StructRefPre`, allocatinga Wasm GC array requires an `ArrayRefPre`, and this is motivated by the samereasons.* fix some doc tests and add docs for Func::wrap-style APIs* Add a comment about why we can't user `iter::repeat(elem).take(len)`* Fix some warnings in no-gc builds List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/gc/enabled/data.rs