October 2023 hybrid meeting agenda

[dtig]

What should we discuss at the next in-person (with virtual attendance options) meeting? Please use this issue to add items you would like to discuss, and are interested in hearing about.

[Maratyszcza]

I suggest we discuss whether Relaxed SIMD is formally considered Stage 4 by now. Relaxed SIMD was conditionally graduated to Stage 4, and even though the condition is satisfied, there's little clarity on whether its officially already at Stage 4.

[RossTate]

If you could find out if there's interest, I could present my preliminary results for addressing the issues of the root scanning design, transforming it from a coarse-grained dynamically typed design for just root scanning to a fine-grained statically typed design for broader stack inspection. I've made sure it keeps things safe and secure and makes it easy for engines to know which locals are inspectable and how they should be laid out, but the new design is much more efficient (in both time and memory) and can be used to support a number of features:

• Debugging
  • Debugging can be implemented in the application (provided the application explicitly marks the relevant locals as inspectable)
  • Debugging information (like DWARF) can be loaded by the application (importing the relevant JS hooks) on demand, rather than having to be shipped with the core application binary (again, provided the core application binary at least marks the relevant locals as inspectable)
• Stack-Allocated Memory
  • Support variadic argument passing by passing the callee a reference to an array embedded within the caller's frame
  • Support stack-allocated data structures (such as in C# and Go) and stack-allocated closures (such as in Swift)
  • Support passing a callee a window into the caller's memory, where the window's lifetime is guaranteed to be restricted to the lifetime of the call (probably useful for implement component-model adapter functions in wasm)
• Advanced Exceptions
  • Long jump
  • Two-phase exception handling
  • Custom in-application stack tracing (even java.lang.StackWalker)
• Memory Management
  • Reference counting + long jump (see Reintroducing exnref exception-handling#280 (comment))
  • Conservate linear-memory GC (e.g. Boehm-Demers-Weiser)
  • Precise linear-memory GC (see Proposal: Stack Walking design#1340 (comment))
• Work sharing (in combination with stack-switching and threads proposals)
  • Would enable statically identifying which stacks are safe to share across threads (i.e. don't have unshareable references stored in any stack frames)
• Profiling
  • Application can inspect its frames to identify which of its functions are in use (provided the frames have been explicitly marked with such inspectable information)
• Streaming-Compiler Efficiency
  • The frame information needed to do this well also provides streaming engines with the information to easily know when locals are alive (and initialized) or dead, and to better know how they should be placed on the stack or in registers, making it possible for engines to produce much more memory-and-time efficient assembly on the first pass.

This is a hard problem, and it'll take time to put a presentation together, so I only want to go through that effort if there's at least some established interest among the community and willingness among the engine and tool maintainers.

[tlively]

I only want to go through that effort if there's at least some established interest among the community and willingness among the engine and tool maintainers.

There's a bit of a chicken and egg problem there. How will implementers and users become interested in the proposal (or know they are unwilling to implement and use it) if they don't know what the proposal is? If you're ok presenting to raise awareness and gather feedback, then that sounds great, but I would not expect toolchain or engine implementers to work on anything until their users are positioned to benefit from it.

[RossTate]

Oh, sorry, I wasn't asking if people would commit to a design before seeing it. I was asking: if there were a design that supported the features mentioned above in a way that key teams found promising, is there sufficient interest that key teams would work on it presently? I know a number of language teams have communicated a desire for stack inspection, but I also understand that resources for adding new features to WebAssembly are limited, and I do not know where support for this feature would stand in terms of priorities for the key teams.

[wingo]

Hi, if there is interest, I would be happy to give a report on Spritely's use of GC as a target for Scheme compilation. Relative to the presentation given to the GC subgroup in April, we have pretty much finished the MVP. Some points of interest:

• Strategy for producing wasm/gc as back-end of an existing optimizing compiler
• Types: what worked well, what we need to do better, what GC needs to do
• Strings: what stringref did for us, our plans for shipping without stringref support
• Future extensions that would make wasm/gc a better target
• Tooling: we ended up building a full toolchain including an interpreting VM, for development purposes

[zapashcanon]

Hi,

With @chambart we could talk about two subjects:

• recent progress on compiling OCaml to WasmGC (Wasocaml) ;
• efficient symbolic execution of Wasm (Owi).

Note that we proposed the two talks to the Wasm research day so it may be a good idea to sync in some way so we don't present twice and we present to the audience for which it makes more sense. :)

[dtig]

@Maratyszcza There's a profiles discussion coming up on the 26th, I was hoping we could also bundle a Relaxed SIMD vote into the same discussion and bump to the October meeting if not resolved, wdyt?

@RossTate At least for V8, we're in the process of implementing several proposals, I don't expect that we'll be able to invest in stack inspection (design and/or implementation feedback) in the short term. It may be the same case for other engines, though I'm not able to speak for them. If you've already had interest, and would like to present I can add an agenda item to the list.

@wingo I'll add to the agenda list, I think the feedback on future extensions, tooling, and the stringref discussion would be interesting to the group. Would 30-45 mins be a good time box for the discussion?

@zapashcanon, thanks for the note - I'll coordinate offline with @titzer for coordination between the CG meeting and research day.

[wingo]

@wingo I'll add to the agenda list, I think the feedback on future extensions, tooling, and the stringref discussion would be interesting to the group. Would 30-45 mins be a good time box for the discussion?

Sounds great to me. Yes 30-45 mins sgtm; could easily fill 45 min. Happy to adapt to what's available, though.

[dtig]

Thanks, added in #1371 with 45 mins for now, may adjust as more agenda items are added.

[RossTate]

Got it, @dtig. Thanks for looking into it! I'll save it for another time then.

[Maratyszcza]

@dtig I'm good on discussing Stage 4 Relaxed SIMD on Sep 26th together with profiles

[vouillon]

Hi,
I have submitted a talk to the Wasm Research Day on how I'm adapting Js_of_ocaml (a compiler from OCaml to JavaScript) to produce WebAssembly instead: Wasm_of_ocaml: compiling OCaml bytecode to WebAssembly. But I could give it at the CG meeting if this seems more appropriate.
I plan to talk in particular on how we interface with JavaScript, allowing to compile and run existing code with minimal changes, and on how we are relying on JavaScript to supplement some currently missing functionalities in WebAssembly.

[rossberg]

@vouillon, personally, I think this would be of interest to the wider CG, not just the research folks.