3 ms·

That's an orthogonal problem. First it needs to be possible and straightforward to write GCed languages in the sandbox. Second, GCed languages need to be willin

That's an orthogonal problem. First it needs to be possible and straightforward to write GCed languages in the sandbox. Second, GCed languages need to be willing to fit with the web/WASM GC model, which may not exactly match their own GC and which won't use their own GC. And after that, languages with runtimes could start trying to figure out how they might reduce the overhead of having a runtime.

cogman10 8mo ago
> Second, GCed languages need to be willing to fit with the web/WASM GC model I think most languages could pretty easily use WASM GC. The main issue comes around FFI. That's where things get nasty.
- pjmlp 8mo ago
  WasmGC doesn't support interior pointers, and is quite primitive in available set of operations, this is quite relevant if you care about performance, as it would be a regression in many languages, hence why it has largely been ignored, other than the runtimes that were part of the announcement.
  - cogman10 8mo ago
    Oh interesting. In java land the fact that you effectively don't have pointers but rather everything is an object reference, this ends up not being an issue. I wonder if the WASM limitation is related to the fact that JavaScript has pretty similar semantics with no real concept of a "pointer". It means to get that interior pointer, you'd need to also introduce that concept into the GC of browsers which might be a bit harder since it'd only be for WASM.
    - Rohansi 8mo ago
      Object references are pointers. WasmGC only supports pointers which point to the start of an object. However, some languages have features which require pointers that point inside of an object while still keeping that object alive. Limiting WASM to what is capable in JavaScript is quite a silly thing to do. But at the same time there are vastly different GC requirements between runtimes so it's a challenging issue. Interior pointers is only one issue!
      - cogman10 8mo ago
        > Object references are pointers I know this is pedantic, but they aren't. At least not in the sense of what it means for something to be a pointer. Object references are an identifier of an object and not a memory pointer. The runtime takes those object references and converts them into actual memory addresses. It has to do that because the position of the object in memory (potentially) changes every time a GC runs. This does present it's own problems. Different runtimes make different choices around this. Go and python do not move objects in memory. As a result, it's a lot easier for them to support interior and regular pointers being actual pointers. But that also means they are slower to allocate, free, and they have memory fragmentation issues. I'm not sure about C# (the only other language I saw with interior pointers). I think C# semi-recently switched over to a moving collector. In which case, I'm curious to know how they solved the interior pointer problem.
        Rohansi 8mo ago
        > I'm not sure about C# (the only other language I saw with interior pointers). I think C# semi-recently switched over to a moving collector. In which case, I'm curious to know how they solved the interior pointer problem. Objects references are just pointers in .NET. See the JIT disassembly below. It's been using a moving GC for a long time, too. https://sharplab.io/#v2:C4LghgzgtgNAJiA1AHwAICYCMBYAUKgZgAIMiBhIgbzyNpOIFcA7CMAMwFMSAWIgWQAUASio064gG5gATkThhgYIgF4iTDgHciAIwCewDgG1MABhMBdANxjxteYsMB2cyqIBOa7lt0psgB6uqJgAdABKzMAAllAcwWQA9lAADpEANhzSAMoZEpEAxhwQwQCqLOyxAIIQAArxkUwG0gLSHGxyCmCGAKzmQp7iAL54A0A= https://sharplab.io/#v2:C4LghgzgtgNAJiA1AHwAICYCMBYAUKgZgAIM...
        cogman10 8mo ago
        Interesting. I wonder how C# handles the moving. I'm guessing it has to go in and fix up the pointers in the stack after a gc run? Or is this some OS level virtual pointer weirdness going on? How does C# guard against someone doing something silly like turning a pointer into a long and then back into a pointer again later?
        8mo ago
discreteevent 8mo ago
> Second, GCed languages need to be willing to fit with the web/WASM GC model Suppose the Go people make a special version of Go for Wasm. What do you think are the chances of that being supported in 5 years time?
- JoshTriplett 8mo ago
  I think it'd be supported by them the moment they ship it. Whether others will be excited to use it is an open question. There's no central registry of "languages supported for WebAssembly", by design; it supports any language that can compile to standards-compliant WebAssembly.

cogman10 8mo ago

> Second, GCed languages need to be willing to fit with the web/WASM GC model I think most languages could pretty easily use WASM GC. The main issue comes around FFI. That's where things get nasty.

pjmlp 8mo ago
WasmGC doesn't support interior pointers, and is quite primitive in available set of operations, this is quite relevant if you care about performance, as it would be a regression in many languages, hence why it has largely been ignored, other than the runtimes that were part of the announcement.
- cogman10 8mo ago
  Oh interesting. In java land the fact that you effectively don't have pointers but rather everything is an object reference, this ends up not being an issue. I wonder if the WASM limitation is related to the fact that JavaScript has pretty similar semantics with no real concept of a "pointer". It means to get that interior pointer, you'd need to also introduce that concept into the GC of browsers which might be a bit harder since it'd only be for WASM.
  - Rohansi 8mo ago
    Object references are pointers. WasmGC only supports pointers which point to the start of an object. However, some languages have features which require pointers that point inside of an object while still keeping that object alive. Limiting WASM to what is capable in JavaScript is quite a silly thing to do. But at the same time there are vastly different GC requirements between runtimes so it's a challenging issue. Interior pointers is only one issue!
    - cogman10 8mo ago
      > Object references are pointers I know this is pedantic, but they aren't. At least not in the sense of what it means for something to be a pointer. Object references are an identifier of an object and not a memory pointer. The runtime takes those object references and converts them into actual memory addresses. It has to do that because the position of the object in memory (potentially) changes every time a GC runs. This does present it's own problems. Different runtimes make different choices around this. Go and python do not move objects in memory. As a result, it's a lot easier for them to support interior and regular pointers being actual pointers. But that also means they are slower to allocate, free, and they have memory fragmentation issues. I'm not sure about C# (the only other language I saw with interior pointers). I think C# semi-recently switched over to a moving collector. In which case, I'm curious to know how they solved the interior pointer problem.
      - Rohansi 8mo ago
        > I'm not sure about C# (the only other language I saw with interior pointers). I think C# semi-recently switched over to a moving collector. In which case, I'm curious to know how they solved the interior pointer problem. Objects references are just pointers in .NET. See the JIT disassembly below. It's been using a moving GC for a long time, too. https://sharplab.io/#v2:C4LghgzgtgNAJiA1AHwAICYCMBYAUKgZgAIMiBhIgbzyNpOIFcA7CMAMwFMSAWIgWQAUASio064gG5gATkThhgYIgF4iTDgHciAIwCewDgG1MABhMBdANxjxteYsMB2cyqIBOa7lt0psgB6uqJgAdABKzMAAllAcwWQA9lAADpEANhzSAMoZEpEAxhwQwQCqLOyxAIIQAArxkUwG0gLSHGxyCmCGAKzmQp7iAL54A0A= https://sharplab.io/#v2:C4LghgzgtgNAJiA1AHwAICYCMBYAUKgZgAIM...
        cogman10 8mo ago
        Interesting. I wonder how C# handles the moving. I'm guessing it has to go in and fix up the pointers in the stack after a gc run? Or is this some OS level virtual pointer weirdness going on? How does C# guard against someone doing something silly like turning a pointer into a long and then back into a pointer again later?
        8mo ago

discreteevent 8mo ago

> Second, GCed languages need to be willing to fit with the web/WASM GC model Suppose the Go people make a special version of Go for Wasm. What do you think are the chances of that being supported in 5 years time?

JoshTriplett 8mo ago
I think it'd be supported by them the moment they ship it. Whether others will be excited to use it is an open question. There's no central registry of "languages supported for WebAssembly", by design; it supports any language that can compile to standards-compliant WebAssembly.