Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Multithreading Rust and Wasm

rustwasm.github.io

Post reply on HN
Print view View original

31–40 of 47 posts

Re: Multithreading Rust and Wasm

#31

Post by nemaar »

klarifie wrote: post #27
jamesfmilne wrote: post #26

Earlier quoted context omitted.

From TFA: WebAssembly modules today are optionally associated with at most one instance of “linear memory”. In non-wasm parlance, you can put a stick of RAM into a wasm module. This WebAssembly.Memory is today always backed by an ArrayBuffer, but you’ll soon be able to flag a memory as “shared” which means it’s backed by SharedArrayBuffer instead. This subsequently means that the structured clone of a WebAssembly.Mem…

This is analogous to different UNIX programs communicating with shmget and a synchronization primitive. It's still a multiprocess model.

Technically, you are right, but if multiple processes use the same shared memory is there a real, meaningful difference? You can do efficient, parallel computation in a browser, does it really matter how it is executed under the hood?

Re: Multithreading Rust and Wasm

#32

Post by hinkley »

monocasa wrote: post #25
amelius wrote: post #23

The ultimate test would be to see if it is possible to implement an efficient concurrent GC in Rust+WASM. This might require memory fence instructions in WASM.

I thought you didn't have raw stack access in wasm, making efficient concurrent GCs impossible practically in native wasm. Hence the GC work to give a higher level API that can more easily be sandboxed.

IBM did a JVM (J9?) that used stack checkpointing and interrupts for some of its GC tasks. GC pauses were nearly instantaneous instead of instantaneous, because all threads have to run to a safe point before the mark phase happens.

Various real time systems have used amortization strategies to spread out GC overhead (eg, each memory allocation will GC up to 10 objects).

There are options available.

Re: Multithreading Rust and Wasm

#33

Post by monocasa »

amelius wrote: post #28
monocasa wrote: post #25

Earlier quoted context omitted.

I thought you didn't have raw stack access in wasm, making efficient concurrent GCs impossible practically in native wasm. Hence the GC work to give a higher level API that can more easily be sandboxed.

Virtualization technology is quite mature now, and allows running low-level code (that can access the stack) with safety. Servers run this type of code all the time! Why would we throw away these achievements, and turn WASM (with its potentially simple instruction set) into a complicated monster, that's prone to security problems through its complexity alone? Also, language designers do not want a GC embedded in thei…

> Why would we throw away these achievements, and turn WASM (with its potentially simple instruction set) into a complicated monster, that's prone to security problems through its complexity alone?

Because sandboxing in process is difficult otherwise. You can't allow the user to control code pointers, but for performance reasons you both need to have the raw pointers on the stack, and need to have semi privileged code in the same process just a function call away. Throwing everything into the process/hardware virtualization models doesn't fit this use case very well. It's why the VM in browsers carefully controls code pointers and is already pulled out to a semi sandboxed process.

And I'll grant you that language implementors want raw stack access to implement their own performant GC; that just doesn't exist yet in wasm.

Re: Multithreading Rust and Wasm

#34

Post by monocasa »

hinkley wrote: post #32
monocasa wrote: post #25

Earlier quoted context omitted.

I thought you didn't have raw stack access in wasm, making efficient concurrent GCs impossible practically in native wasm. Hence the GC work to give a higher level API that can more easily be sandboxed.

IBM did a JVM (J9?) that used stack checkpointing and interrupts for some of its GC tasks. GC pauses were nearly instantaneous instead of instantaneous, because all threads have to run to a safe point before the mark phase happens. Various real time systems have used amortization strategies to spread out GC overhead (eg, each memory allocation will GC up to 10 objects). There are options available.

That's sort of orthogonal to what I'm talking about. The issue is that wasm doesn't yet give you the tools to implement those techniques (namely the ability to do brain surgery on a running stack).

Re: Multithreading Rust and Wasm

#35

Post by TomMarius »

topspin wrote: post #19
jxub wrote: post #9

Goddamn, the frequency of Rust-related articles on the front page must be really telling something positive about this language and its community.

I regularly hit a search [1] to pick up Rust related stories. Most Rust-related articles don't make the front page and most see no comment activity at all. Lately the WASM+Rust stories see a lot of activity. Also, some 'I learned Rust and this is what I think about it' type blog posts attract comments. The rest do not. 10 hours ago: "Ask HN: Rust, anyone?" asking who is using Rust in production. No replies. [1] https…

I completely missed that post even though I'd have definitely replied. Maybe just bad timing.

Re: Multithreading Rust and Wasm

#36

Post by monocasa »

klarifie wrote: post #27
jamesfmilne wrote: post #26

Earlier quoted context omitted.

From TFA: WebAssembly modules today are optionally associated with at most one instance of “linear memory”. In non-wasm parlance, you can put a stick of RAM into a wasm module. This WebAssembly.Memory is today always backed by an ArrayBuffer, but you’ll soon be able to flag a memory as “shared” which means it’s backed by SharedArrayBuffer instead. This subsequently means that the structured clone of a WebAssembly.Mem…

This is analogous to different UNIX programs communicating with shmget and a synchronization primitive. It's still a multiprocess model.

At that point, the distinction between threads and processes gets really muddy even when you're not using wasm. clone(2) is just a superset of fork(2) that lets you decide whether to share memory or not (among other resources).

Re: Multithreading Rust and Wasm

#37

Post by hinkley »

monocasa wrote: post #34
hinkley wrote: post #32

Earlier quoted context omitted.

IBM did a JVM (J9?) that used stack checkpointing and interrupts for some of its GC tasks. GC pauses were nearly instantaneous instead of instantaneous, because all threads have to run to a safe point before the mark phase happens. Various real time systems have used amortization strategies to spread out GC overhead (eg, each memory allocation will GC up to 10 objects). There are options available.

That's sort of orthogonal to what I'm talking about. The issue is that wasm doesn't yet give you the tools to implement those techniques (namely the ability to do brain surgery on a running stack).

My point is that there are other things you can do that don't involve modifying the stack (or at least, except via inlined code).

Re: Multithreading Rust and Wasm

#38

Post by zamadatix »

amelius wrote: post #28
monocasa wrote: post #25

Earlier quoted context omitted.

I thought you didn't have raw stack access in wasm, making efficient concurrent GCs impossible practically in native wasm. Hence the GC work to give a higher level API that can more easily be sandboxed.

Virtualization technology is quite mature now, and allows running low-level code (that can access the stack) with safety. Servers run this type of code all the time! Why would we throw away these achievements, and turn WASM (with its potentially simple instruction set) into a complicated monster, that's prone to security problems through its complexity alone? Also, language designers do not want a GC embedded in thei…

Can you clarify what you mean by "virtualization technology". It's a pretty broad term ranging from hardware assisted system virtualization to application virtualization to containerization. All of these types are run on servers all the time but each has very different performance and security characteristics.

Re: Multithreading Rust and Wasm

#39

Post by monocasa »

hinkley wrote: post #37
monocasa wrote: post #34

Earlier quoted context omitted.

That's sort of orthogonal to what I'm talking about. The issue is that wasm doesn't yet give you the tools to implement those techniques (namely the ability to do brain surgery on a running stack).

My point is that there are other things you can do that don't involve modifying the stack (or at least, except via inlined code).

I just don't understand how you implement stack checkpointing without access to the stack.

Re: Multithreading Rust and Wasm

#40

Post by woah »

monocasa wrote: post #25
amelius wrote: post #23

The ultimate test would be to see if it is possible to implement an efficient concurrent GC in Rust+WASM. This might require memory fence instructions in WASM.

I thought you didn't have raw stack access in wasm, making efficient concurrent GCs impossible practically in native wasm. Hence the GC work to give a higher level API that can more easily be sandboxed.

Are they really trying to put a GC into wasm? Sounds like a monstrosity.
Post reply on HN