[ruby-core:107408] [Ruby master Feature#18462] Proposal to merge WASI based WebAssembly support

Issue #18462 has been updated by jez (Jake Zimmerman).


mame (Yusuke Endoh) wrote in #note-4:
> Feel free to ask me if you have a question.

Wow, thanks for putting this together! I did in fact have a question, but I figure we can move the conversation somewhere else to keep this Ruby ticket on topic (discussing the WASI support).

→ https://github.com/mame/emruby/issues/6

----------------------------------------
Feature #18462: Proposal to merge WASI based WebAssembly support
https://bugs.ruby-lang.org/issues/18462#change-96307

* Author: katei (Yuta Saito)
* Status: Open
* Priority: Normal
----------------------------------------
# Proposal to merge WASI based WebAssembly support

This is an initial port of WASI based WebAssembly support.
This enables a CRuby binary to be available on Web browser, Serverless Edge environment, and other WebAssembly/WASI embedders. 
Currently this port passes basic and bootstrap test suites not using Thread API.

The upstreaming PR on ruby/ruby is here: https://github.com/ruby/ruby/pull/5407

## Background

For example, CRuby already supports WebAssembly target by Emscripten, but Emscripten heavily depends on JavaScript to emulate some missing features in WebAssembly itself.

In short the WASI is an effort to define a standard set of syscalls for WebAssembly modules, allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The environments includes non JS environments, Edge Computing platforms, IoT devices, and so on.

This is a proposal ticket to support WASI based WebAssembly target.

This is a part of Ruby Association Grant project

## Lexicon

- [WASI](https://wasi.dev): A system call interface for WebAssembly
- [wasi-libc](https://github.com/WebAssembly/wasi-libc): A libc implementation for WebAssembly programs built on top of WASI system calls.

## Current Limitation of WebAssembly and WASI

### Threads

Currently WebAssembly has no threads, and WASI doesn't provide any API to create a thread, but they are [on the roadmap](https://github.com/WebAssembly/threads/blob/main/proposals/threads/Overview.md). This means `Thread.new` doesn't work on this target, and it raises `ENOSUP` for now.

### Register operations

Current WebAssembly doesn't allow to touch the program counter, but they are also [on the roadmap](https://github.com/WebAssembly/stack-switching).
This limitation makes it hard to implement setjmp/longjmp and context-switching on this target, and wasi-libc doesn't provide such implementations.

And also WebAssembly has function local infinite registers, but there is no way to scan the values in a call stack for now.
This limitation makes it unable to mark living objects by Conservative GC in a simple way.

## Patch Overview

This patch is a set of minor changes:

### Adapt to wasi-libc API

wasi-libc is almost compatible with other libc implementations, but it doesn't have some functions.
So this patch adds stub implementations for them.

### Add no thread variant

As mentioned above, WebAssembly has no thread, so this patch adds a thread_none.c, which is a sibling of thread_win32.c and thread_pthread.c. This implementation does nothing around preemptive context switching because there is no native thread.

### Emulate setjmp/longjmp, coroutine, and register scan by Asyncify

As mentioned above, WebAssembly has no context switching feature, but there is an userland technique to pause and resume a WebAssembly process by binary transformation.
This technique is called [Asyncify](https://kripken.github.io/blog/wasm/2019/07/16/asyncify.html).
This patch utilizes it to emulate setjmp/longjmp, coroutine, and register scan for GC.





-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>