Merge with upstream #170
Merged
Merge with upstream #170
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…nce#8592) Since there are no calls left to AllocationConsumer's methods, this commit just deletes all the arguments of this type, as well as the definition of the type itself.
* riscv64: Improve pattern matching rules for FMA. This commit reworks our FMA pattern matching to be slightly less verbose. It additionally adds the `(fma x (splat y) z)` pattern for vectors, which can be proven to be equivalent to `(splat x)`. Co-Authored-By: Jamey Sharp <[email protected]> * riscv64: Remove unused rule priority --------- Co-authored-by: Jamey Sharp <[email protected]>
…e#8604) Part of the ongoing saga of bytecodealliance#8524, bytecodealliance#8566, bytecodealliance#8581, and bytecodealliance#8592
* Add Android release binaries to CI This commit is inspired by bytecodealliance#6480 and historical asks for Android binaries. This does the bare minimum necessary to configure C compilers such that we can produce binaries but I'll admit that I'm no Android developer myself so I have no idea if these are actually suitable for use anywhere. Otherwise though this build subsumes the preexisting check in CI that the build works for Android, so that part is removed too. This additionally changes how the NDK is managed from before. Previously a GitHub Action was used to download Java and the NDK and additionally used the `cargo ndk` subcommand. That's all removed now in favor of configuring C compilers directly with a pre-installed version of the NDK which should help reduce the CI dependencies a bit. * Review comments * List Android as tier 3 target
* Move wast tests to their own test suite This commit moves testing of `*.wast` files out of the `all` test suite binary and into its own separate binary. The motivation for this is well-described in bytecodealliance#4861 with one of the chief reasons being that if the test suite is run and then a new file is added re-running the test suite won't see the file. The `libtest-mimic` crate provides an easy way of regaining most of the features of the `libtest` harness such as parallel test execution and filters, meaning that it's pretty easy to switch everything over. The only slightly-tricky bit was redoing the filter for whether a test is ignored or not, but most of the pieces were copied over from the previous `build.rs` logic. Closes bytecodealliance#4861 * Fix the `all` suite * Review comments
) The egraph pass and the dead-code elimination pass both remove instructions whose results are unused. If the optimization level is "none", neither pass runs, and if it's anything else both passes run. I don't think we should do this work twice. Note that the DCE pass is different than the "eliminate unreachable code" pass, which removes entire blocks that are unreachable from the entry block. That pass might still be necessary.
…dealliance#8448) * Remove unused generated `add_root_to_linker` method * WIP: bindgen GetHost * Compile with Rust 1.78+ Use <https://users.rust-lang.org/t/generic-closure-returns-that-can-capture-arguments/76513/3> as a guide of how to implement this by making the `GetHost` trait a bit uglier. * Add an option to skip `&mut T -> T` impls Also enable this for WASI crates since they do their own thing with `WasiView` for now. A future refactoring should be able to remove this option entirely and switch wasi crates to a new design of `WasiView`. * Update test expectations * Review comments * Undo temporary change * Handle some TODOs * Remove no-longer-relevant note * Fix wasmtime-wasi-http doc link --------- Co-authored-by: Alex Crichton <[email protected]>
…ce#8595) This is the final type system change for Wasm GC: the ability to explicitly declare supertypes and finality. A final type may not be a supertype of another type. A concrete heap type matches another concrete heap type if its concrete type is a subtype (potentially transitively) of the other heap type's concrete type. Next, I'll begin support for allocating GC structs and arrays at runtime. I've also implemented `O(1)` subtype checking in the types registry: In a type system with single inheritance, the subtyping relationships between all types form a set of trees. The root of each tree is a type that has no supertype; each node's immediate children are the types that directly subtype that node. For example, consider these types: class Base {} class A subtypes Base {} class B subtypes Base {} class C subtypes A {} class D subtypes A {} class E subtypes C {} These types produce the following tree: Base / \ A B / \ C D / E Note the following properties: 1. If `sub` is a subtype of `sup` (either directly or transitively) then `sup` *must* be on the path from `sub` up to the root of `sub`'s tree. 2. Additionally, `sup` *must* be the `i`th node down from the root in that path, where `i` is the length of the path from `sup` to its tree's root. Therefore, if we maintain a vector containing the path to the root for each type, then we can simply check if `sup` is at index `supertypes(sup).len()` within `supertypes(sub)`.
…nce#8608) * Change `MemoryStyle::Static` to store bytes, not pages This commit is inspired by me looking at some configuration in the pooling allocator and noticing that configuration of wasm pages vs bytes of linear memory is somewhat inconsistent in `Config`. In the end I'd like to remove or update the `memory_pages` configuration in the pooling allocator to being bytes of linear memory instead to be more consistent with `Config` (and additionally anticipate the custom-page-sizes wasm proposal where terms-of-pages will become ambiguous). The first step in this change is to update one of the lowest layered usages of pages, the `MemoryStyle::Static` configuration. Note that this is not a trivial conversion because the purpose of carrying around pages instead of bytes is that bytes may overflow where overflow-with-pages typically happens during validation. This means that extra care is taken to handle errors related to overflow to ensure that everything is still reported at the same time. * Update crates/wasmtime/src/runtime/vm/instance/allocator/pooling/memory_pool.rs Co-authored-by: Nick Fitzgerald <[email protected]> * Fix tests * Really fix tests --------- Co-authored-by: Nick Fitzgerald <[email protected]>
This introduces a `DecommitQueue` for batching decommits together in the pooling allocator: * Deallocating a memory/table/stack enqueues their associated regions of memory for decommit; it no longer immediately returns the associated slot to the pool's free list. If the queue's length has reached the configured batch size, then we flush the queue by running all the decommits, and finally returning the memory/table/stack slots to their respective pools and free lists. * Additionally, if allocating a new memory/table/stack fails because the free list is empty (aka we've reached the max concurrently-allocated limit for this entity) then we fall back to a slow path before propagating the error. This slow path flushes the decommit queue and then retries allocation, hoping that the queue flush reclaimed slots and made them available for this fallback allocation attempt. This involved defining a new `PoolConcurrencyLimitError` to match on, which is also exposed in the public embedder API. It is also worth noting that we *always* use this new decommit queue now. To keep the existing behavior, where e.g. a memory's decommits happen immediately on deallocation, you can use a batch size of one. This effectively disables queueing, forcing all decommits to be flushed immediately. The default decommit batch size is one. This commit, with batch size of one, consistently gives me an increase on `wasmtime serve`'s requests-per-second versus its parent commit, as measured by `benches/wasmtime-serve-rps.sh`. I get ~39K RPS on this commit compared to ~35K RPS on the parent commit. This is quite puzzling to me. I was expecting no change, and hoping there wouldn't be a regression. I was not expecting a speed up. I cannot explain this result at this time. prtest:full Co-authored-by: Jamey Sharp <[email protected]>
Open
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.