Wasmtime GitHub notifications bot (Aug 31 2026 at 16:20): Wasmtime GitHub notifications bot (Aug 31 2026 at 16:20):avanhatt opened PR #14243 from avanhatt:isle-veri-timeout to bytecodealliance:main:
Per discussion in #14207, switch the CI verifier to run the full configuration but with a lower timeout (expecting some
unknowns). See how long this takes with a partially-warm cache.
Wasmtime GitHub notifications bot (Aug 31 2026 at 16:20):avanhatt requested wasmtime-compiler-reviewers for a review on PR #14243.
Wasmtime GitHub notifications bot (Aug 31 2026 at 16:20):avanhatt requested cfallin for a review on PR #14243.
Wasmtime GitHub notifications bot (Aug 31 2026 at 16:20):avanhatt requested alexcrichton for a review on PR #14243.
Wasmtime GitHub notifications bot (Aug 31 2026 at 16:20):avanhatt requested wasmtime-default-reviewers for a review on PR #14243.
Wasmtime GitHub notifications bot (Aug 31 2026 at 19:44):github-actions[bot] added the label cranelift on PR #14243.
Wasmtime GitHub notifications bot (Aug 31 2026 at 19:44):github-actions[bot] added the label isle on PR #14243.
Wasmtime GitHub notifications bot (Aug 31 2026 at 19:45):github-actions[bot] commented on PR #14243:
Subscribe to Label Action
cc @avanhatt, @cfallin, @fitzgen, @mmcloughlin
<details>
This issue or pull request has been labeled: "cranelift", "isle"Thus the following users have been cc'd because of the following labels:
- avanhatt: isle
- cfallin: isle
- fitzgen: isle
- mmcloughlin: isle
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
Wasmtime GitHub notifications bot (Aug 31 2026 at 20:20):alexcrichton commented on PR #14243:
Looks like 3h for a full run where the first set of cache stats are:
========================== Cache statistics =========================== Mode: read-write Source: cranelift/isle/veri/cache Destination: cranelift/isle/veri/cache.rebuild Hits: 1219 (2.4%) Misses: 50062 (97.6%) New entries: 50062 Retained: 1213 Source entries: 12200 Dropped (unused):10987I'm going to trigger a rebuild and see what happens with what should presumably now be a fresh cache
Wasmtime GitHub notifications bot (Aug 31 2026 at 20:30):alexcrichton commented on PR #14243:
And a warm cache took ~5m with the first cache stats as:
========================== Cache statistics =========================== Mode: read-write Source: cranelift/isle/veri/cache Destination: cranelift/isle/veri/cache.rebuild Hits: 51281 (100.0%) Misses: 0 (0.0%) New entries: 0 Retained: 51275 Source entries: 65582 Dropped (unused):14307y'all may know more about what's going on here, but the CI output says:
Dropped (unused):14307 ... Dropped (unused):51600 ... Dropped (unused):65257so I've kicked it again for a 3rd run just to confirm that a warm=>warm cache is handled ok
Wasmtime GitHub notifications bot (Aug 31 2026 at 21:09):cfallin commented on PR #14243:
y'all may know more about what's going on here
Aaargh, I just realized what's going on: we are doing the "shrink the cache to only what was used" GC, but we're doing that separately for two different runs (mid-end and backend), so one of them runs and deletes the cached entries used by the other, and then the other runs and deletes the entries just kept by the first.
Very very silly and this is my harness bug -- sorry about that! @avanhatt the easiest fix (rather than trying to factor out the GC step and keep out-of-band "mark bits" somehow) may be to combine everything into one run; would you be willing to do that in this PR (one args file that specifies all three runs we do today)?
Wasmtime GitHub notifications bot (Aug 31 2026 at 21:45):alexcrichton commented on PR #14243:
That may not actually be necessary, although I'm not entirely sure why? The 3rd run in CI here, which started with a warm cache generated by a previous run which generated a "warm cache" ran in 5 minutes, like the 2nd run. Given that it looks like caching is working so I'm not sure if there's actually an issue here other than perhaps slightly confusing output which is no biggie really
Wasmtime GitHub notifications bot (Aug 31 2026 at 21:53):cfallin commented on PR #14243:
Ah, yes, you're right of course -- we rebuild everything into
cache.rebuildbefore renaming it over the originalcache; sorry, forgot already that I had built it this way (small L1 cache these days!).
Wasmtime GitHub notifications bot (Aug 31 2026 at 21:53):cfallin commented on PR #14243:
(So to be clear what's going on: the "dropped" in each of the three runs is counting input cache entries that are not copied over; but the final cache is a union of all non-dropped entries from all three runs, since an entry is just a file named with a hash)
Wasmtime GitHub notifications bot (Aug 31 2026 at 21:57):alexcrichton commented on PR #14243:
Makes sense! This all looks good to me, but I'll defer to you @cfallin for the approval since you're more familiar with these bits
Wasmtime GitHub notifications bot (Aug 31 2026 at 22:01)::thumbs_up: cfallin submitted PR review:
LGTM -- will go ahead and put this on the queue but if the delay on the merge queue becomes an issue, we can skip other entries ahead of this one...
Wasmtime GitHub notifications bot (Aug 31 2026 at 22:01):cfallin added PR #14243 ISLE: veri: full run, lower timeout. to the merge queue
Wasmtime GitHub notifications bot (Sep 01 2026 at 01:07)::check: cfallin merged PR #14243.
Wasmtime GitHub notifications bot (Sep 01 2026 at 01:07):cfallin removed PR #14243 ISLE: veri: full run, lower timeout. from the merge queue
Last updated: Sep 20 2026 at 18:08 UTC