Stream: Events

Topic: Plumbers Summit - October 2026

David Bryant (Oct 09 2026 at 20:13):

We're pleased to invite you to the next installment in our series of ongoing Bytecode Alliance Plumbers Summits, to be held Wednesday October 28, 2026. This will be an all on-line event supporting full remote participation for anyone anywhere, in three-hour sessions each day that will be recorded so they can be viewed anytime afterward via our YouTube channel.  Watch this topic for more information leading up to the event and as a live conversation during the event itself.

Thank you for your support of the Alliance, our projects, and our community!  We hope you’ll join us for our next Plumbers Summit!

David Bryant (Oct 16 2026 at 16:58):

The planned agenda for the event is now available via our general meeting information repository here. Additional details will be provided both there and here to help you plan for and attend the event.

All times are US Pacific Daylight (GMT-7):

• Welcome - Oscar Spencer
• 8:00 - 8:45 - Luke Wagner – “Component Model Update”
• 8:45 - 8:50 - Quick break
• 8:50 - 9:20 - Chris Fallin – “Debugging”
• 9:20 - 9:40 - Alex Crichton – “Toolchains and Cooperative Threads”
• 9:40 - 10:00 - Joel Dice – “Guest Languages Update”
• 10:00 - 10:20 - Till Schneidereit – “StarlingMonkey Next”
• 10:20 - 10:30 - Quick break
• 10:30 - 11:15 - “Collaborating in the Age of AI” (Till & Oscar, facilitating)
• 11:15 - 12:00 - Lunch and hallway conversations (with Zoom breakout rooms)
• 12:00 - 1:00 - Games
• Wrap-up and Thanks - Oscar Spencer

David Bryant (Oct 27 2026 at 21:41):

We're hoping you're planning to attend tomorrow's Plumbers Summit Event! You're welcome to join the hosted Zoom meeting directly (link), or can participate through the event livestream on YouTube (link). Details and both those links are also in the event's README in our meetings repository.

We'll get started at 8am US Pacific Daylight Time tomorrow (Wednesday, October 28).

fitzgen (he/him) (Oct 28 2026 at 15:00):

let's gooooo

Yosh Wuyts (Oct 28 2026 at 15:02):

hellooo

David Bryant (Oct 28 2026 at 15:03):

Hello, everyone -- thanks for joining us!

Bailey Hayes (Oct 28 2026 at 15:29):

Question for Luke - re: getters/setters, in wasi we aligned to having a get- prefix for getters knowing this is the direction we were heading (ty Dave). When wasi adopts the CM feature as stabilized we could begin using the feature. Is there a way to do this in a non-breaking way for existing WIT definitions that already have the prefix?

Alex Crichton (Oct 28 2026 at 15:32):

IIRC the validation rules would allow:

get-foo: func() -> u32;
foo: get() -> u32;

so I believe adding get and set functions for various properties alongside the preexisting get/set functions should work well

Bailey Hayes (Oct 28 2026 at 15:42):

and so wit-bindgen or other generators will want to special case the previous get- prefixed ones if there's a canonical getter to map to canonical getter func just to have an eventual deprecation path off the old func

Yosh Wuyts (Oct 28 2026 at 16:15):

yay, debugging support for components!

Yosh Wuyts (Oct 28 2026 at 16:29):

https://dl.acm.org/doi/10.1145/349299.349339 <- paper Chris mentioned

Ryan Hunt (Oct 28 2026 at 16:32):

@Chris Fallin Very cool! I maybe missed it, but how are you handling externref for snapshots? Also do you have a link to the slides or code prototypes?

Chris Fallin (Oct 28 2026 at 16:34):

great question @Ryan Hunt ! So the question is what you can do with an externref: just plumb it through and pass it back out to a hostcall, right? During replay hostcalls are stubbed out and only exist for their side-effects; so externrefs are just opaque meaningless things. (I don't remember whether I gave them unique ids or just made them Unit but the debugger can't introspect them either so at least in Wasmtime it doesn't matter)

Chris Fallin (Oct 28 2026 at 16:34):

re: code and slides: soon!

Lucy Menon (Oct 28 2026 at 16:36):

@Chris Fallin I really liked the watchpoint CoW scheme. I'm kind of curious how that works/whether there are scalability limits on it, since one usually has a pretty limited number of watchpoint ranges available?

Also: a bit out of scope for this talk, but looking to the future since you mentioned heisendebugging earlier: do you have any thoughts on whether/how you might be able to in the future explore thread schedules/weak memory interleavings when multiple parallel threads (e.g. via shared-everything thread.new) arrive?

Chris Fallin (Oct 28 2026 at 16:39):

@Lucy Menon great questions!

• watchpoints: the high-level idea is that we have a shadow memory that is 1-to-1 with the memory it's attached to. On a store, we first load the same width/offset and check if nonzero in the shadow, and libcall for debug event if so. (So, "software watchpoints"). So fully scalable, at the cost of a constant tax on every store instruction.
• Thread schedules and memory interleavings in shared-memory threads: interesting! I have some vague handwavy thoughts about enforcing determinism with "write protection" via the above watch points, similar to how we capture dirty pages; basically a software cache coherence algorithm. I guess in principle we then have a choice-point when we have multiple waiters for a page and we could instrument to tweak that for testing/exploration if we wanted to...

fitzgen (he/him) (Oct 28 2026 at 16:40):

probably a chaos-mode scheduler would be an orthogonal option, and the deterministic recording would just replay the scheduling that chaos-mode chose exactly

Chris Fallin (Oct 28 2026 at 16:42):

Yes, exactly

Alex Crichton (Oct 28 2026 at 16:50):

coop threading slides from me

Chris Fallin (Oct 28 2026 at 16:53):

debugging slides (and this link + branches to go to agenda file in meetings repo soon)

Lucy Menon (Oct 28 2026 at 16:54):

(@chris) Ah, I missed the "software" qualifier on watchpoint! That makes a lot of sense, thanks

Chris Fallin (Oct 28 2026 at 16:55):

@Lucy Menon yep! a nice side-effect of this is that r/r, snapshots, reversibility work on Every Wasmtime Platform (**with virtual memory, for the fixed-pointer-of-memory thing) -- vs. e.g. rr that works only on Linux

David Bryant (Oct 28 2026 at 17:04):

All the slides from this morning's presentations so far are now available via the meetings repo here.

Chris Fallin (Oct 28 2026 at 17:10):

(Just pushed links to the demo branches in the doc as well. All of this will be upstreamed hopefully "real soon now")

Yosh Wuyts (Oct 28 2026 at 17:26):

WinterTC support would be great for StarlingMonkey!

Tomasz Andrzejak (Oct 28 2026 at 17:30):

Thanks @Till Schneidereit One of the slides talked about linking model, and it looks like wit-dylib is statically linked into starling core module? I think that makes a lot of sense as those calls can be inlined, but iirc wit-dylib only supports dynamic component linking?

Till Schneidereit (Oct 28 2026 at 17:31):

that's what they want you to believe!

Till Schneidereit (Oct 28 2026 at 17:32):

no, you're right: the intended way of using wit-dylib is with dynamic linking. But I ran into some gnarly issues with dynamic linking and vtables when using p3 streams, plus StarlingMonkey as a dylib is a bunch larger than a static build, so I found a way to do a static link for the time being

Till Schneidereit (Oct 28 2026 at 17:33):

or rather, for the dylib part to be a very small layer on top of starling.wasm as a non-dylib

Tomasz Andrzejak (Oct 28 2026 at 17:35):

Interesting! I think adding support to wit-dylib to generate relocatable static object and then hand off inlining to wasm-opt would be an interesting alternative.

Till Schneidereit (Oct 28 2026 at 17:36):

the long-term plan is to have this be focused on dynamic linking though, so we can provide APIs as dylibs instead of having one big binary

Till Schneidereit (Oct 28 2026 at 17:37):

as Alex mentioned briefly, I played around with external dylibs as separate cwasms, and found those to perform really quite well

Yosh Wuyts (Oct 28 2026 at 17:39):

"If any of you are in the sparkling water sub-reddits" - lol

Pat Hickey (Oct 28 2026 at 18:43):

i did a git clone of the velorant repo and cargo build --release, was that the right thing to get around the corp download blocker or what

David Bryant (Oct 28 2026 at 18:55):

Quick feedback form, if you please: https://docs.google.com/forms/d/e/1FAIpQLScmZt9gbUphDwB8RNmS5GCvGMY5fGjAM07a9CpySDzpGwdG1A/viewform?usp=dialog

Last updated: Oct 31 2026 at 23:03 UTC