4 ms·

>Yes, but don't confuse the problem of implementing a garbage collector with the problem of implementing a system that can support a garbage collector. The form

• boomlinde 9y ago
  > In most cases it isn't non-trivial, and that's further compounded by the fact that the GC currently has to be part of the module payload at the moment. My point here is that it is beside the point whether it's trivial or non-trivial to implement a garbage collector. With regards to it having to be part of the module payload, that's how garbage collectors are typically implemented today, meaning it's very practical in the sense that you can just re-target that portion of your language runtime implementation like any other part without making the web a special case. Just target the new instruction set architecture and you have your garbage collector exactly as intended, tuned for the use case you designed it for. > If we're talking strictly implementation difficulty, then interop with VM-managed GC objects may in fact be more difficult; I'm certainly not an expert so I couldn't tell you. It may be more difficult, but in the end also an entirely different problem. If you have implemented a garbage collecting language runtime for your language, you've already solved the problem of garbage collection. > Per the very first sentence of mine you quoted, I never said it was. It certainly is likely to be far from practical, however. My question from the start was about how exactly it is impractical. Your reply focusing on the hardships of implementing a garbage collector and using the VM GC is an interesting side note, and I appreciate the response and discussion, but it ultimately doesn't answer the question. The evidence to my point is a fully functioning garbage collected language runtime compiled seemingly without modification (it's written in ANSI C, after all) for the WebAssembly platform. You can do that now, without additional hurdles and without considering the garbage collection semantics of the browser runtime. That seems very practical to me. It is also very practical to be able to use objects allocated and managed by the browser instead of a contiguous array of memory, but that doesn't somehow make the obvious approach less practical.
  • rl3 9y ago
    >My point here is that it is beside the point whether it's trivial or non-trivial to implement a garbage collector. >My question from the start was about how exactly it is impractical. Your reply focusing on the hardships of implementing a garbage collector and using the VM GC is an interesting side note, and I appreciate the response and discussion, but it ultimately doesn't answer the question. The hardships of the implementation are central to why it's impractical. That said, I think we may be using different definitions of the word impractical here.[0] I'm talking strictly in a general sense, that packaging an entire language's runtime with code is—for most uses right now—not sensible. You are correct in that it's entirely possible to use GCed languages inside wasm, and indeed it has been done—I'm not disputing that. I also understand your point about the multi-platform advantages of keeping the GC portion of the runtime inside of wasm. Funny enough that may turn on its head in the distant future once GC support lands, assuming wasm ends up being a popular compilation target outside of the web. In that case you'd have wasm-managed GC objects on desktop and mobile. >The evidence to my point is a fully functioning garbage collected language runtime compiled seemingly without modification (it's written in ANSI C, after all) for the WebAssembly platform. You can do that now, without additional hurdles and without considering the garbage collection semantics of the browser runtime. That seems very practical to me. Lua is very lightweight. The story changes if you try to compile the .NET, JVM, Go or even V8 runtimes into wasm. All possible, but a hell of a lot more difficult. One case study is Blazor.[1] The FAQ in its own readme states that it's not practical currently due to binary sizes, albeit not for GC-related reasons. But it will be practical. That was the gist of what I was trying to say, that GCed languages (i.e. ones that include their own runtime) are currently not terribly practical relative to the compiled alternatives, most of which are production-ready now. Of course, having seriously evaluated Unreal Engine 4 for web use with its 50MB runtime, I view even Blazor's current 4MB binary size as quite practical, but it depends on the use case. For general web use, 4MB isn't practical. In support of your point, I concede that whether the GC resides in the module or VM is largely immaterial to practicability as a whole. My point was that packaging the runtime with the payload is usually not sensible relative to the alternatives. I regret that I incorrectly generalized my original statement in terms of garbage collection rather than runtime overhead. [0] https://en.oxforddictionaries.com/definition/impractical https://en.oxforddictionaries.com/definition/impractical [1] https://github.com/SteveSanderson/Blazor https://github.com/SteveSanderson/Blazor