This repository was archived by the owner on Apr 25, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 25, 2025. It is now read-only.
Go support #59
Description
I'm not from the Go team, but I've been working on an alternative implementation of the Go compiler+runtime that works well on microcontrollers and WebAssembly called TinyGo. It already supports WebAssembly but does not have a usable GC there. Hence my interest.
I would really like to use a built-in memory manager, but I'm afraid that the current spec would be a very poor fit for the Go language. I've listed the issues here in order of importance.
- Interior pointers are absolutely required to get reasonable performance out of the GC. Without interior pointers, literally every struct member would have to be boxed killing performance and blowing up memory usage. Even a system with fat pointers would be much better than not having interior pointers at all. Also, if it turns out
inrefis commonly used in WebAssembly, implementations may decide to switch to a GC that supports interior pointers transparently to improve performance. Also think of non-browser environments that may be optimized to run Go compiled to WebAssembly, for example. - Nested structs would also be very important, both because Go supports nesting structs (which may have their address taken) but more importantly because many Go types are commonly implemented as aggregate types: slices, strings, interfaces, complex numbers, and (in my implementation) function values.
- Fixed size arrays that are dynamically indexed would again avoid some unnecessary boxing. Go supports fixed size arrays (which are different from slices) that can be struct members, and it would be useful to not need to box those as dynamically-sized array types.
- Go supports arrays and slices of structs, which are normally stored sequentially in memory for efficiency reasons. They aren't used as much as some of the other things I listed, but it would be unfortunate to need to box all of those structs just to get good performance.
There are also some parts of the spec that I think are more complicated than needed, but I should probably write that down in a separate issue to keep things focused.
Activity
rossberg commentedon Jan 30, 2019
Thanks for the feedback. I understand that these limitations make Go a bad fit for the GC proposal at the moment, and we are aware of that. Comparable caveats apply to other languages as well, though regarding different features.
I think the points you list all fall under the extension discussed under “Nesting” in the Overview. This extension definitely is on the roadmap, but we have to start somewhere, and nesting induces quite a bit of additional complexity, so it's not included in the initial feature set.
The cut-off criterion for the MVP proposal roughly is the minimal set of features that allows expressing everything, even if less efficiently. In particular, that means that for the MVP we are willing to accept (a) more indirections and (b) more casts than should be needed once GC support is more complete.
Interior pointers are a particular pain point of Go. The nesting extension will support them, but you will need to use a specific type of interior references throughout, which potentially has a more costly representation as fat pointers. Mind you, the proposal itself does not prescribe that representation, and a Wasm engine could instead choose to implement a GC with true interior pointers, like the Go runtime itself. However, given the implementation cost, combined with the fact that Go probably is the only relevant language that would benefit from this, it is hard to predict whether Wasm engines will be willing to make that investment. Ultimately that will be a question of market pressure on quality of implementation, not of design.
aykevl commentedon Jan 30, 2019
Yeah I'm aware of the constraints and certainly would like to see a MVP ship faster even if it isn't really suited to Go yet. Just wanted to give feedback on the proposal from my perspective.
Interior pointers are by far the most important part, and are perhaps relatively easy to add - no extra constraints on the GC itself, only on the WebAssembly side. I can see how embedding structs and arrays complicates things but those are certainly less critical for Go. Having just interior pointers would already reduce the pain enormously. But again, I can understand if you don't want to add even that to a MVP (as it technically isn't part of a "minimum viable product").
[Interpreter] Decode/encode the data count section (#59)
tlively commentedon Feb 11, 2022
Thanks for raising these issues, @aykevl. I'll close this issue since it isn't actionable for the MVP, but these remain important problems to look at post-MVP.
Merge pull request #59 from WebAssembly/rm_let
mihaiav commentedon Mar 28, 2024
Is there any issue tracking interior pointers? Seems wasm-gc is out but
gostill can't take advantage(efficiently) of it due the lack of interior pointers.tlively commentedon Mar 28, 2024
Not a specific issue, but if we work on adding interior pointers, that would be a separate proposal, so you can watch the proposals repo for it.