3 ms·
But then WASM GC immediately assumes it can be a moving, compacting GC, with no support for interior pointers. There's a reason Go isn't mentioned in the blog
by ncruces 3y ago
But then WASM GC immediately assumes it can be a moving, compacting GC, with no support for interior pointers.
There's a reason Go isn't mentioned in the blog post: the GC is a leaky abstraction.
- saagarjha 3y agoDoes Go leak observable pointers?
- tedunangst 3y agoPeople have certainly written unsafe code which uses uintptr in naughty ways which only work without moving gc, but every piece of documentation for such features also tells you not to do it.
- deleted 3y ago[deleted]
- yencabulator 3y agoIntentionally so: that's the only way to cooperate with C and memory-mapped kernel and hardware ABIs. There is an explicit mechanism to pin memory. https://pkg.go.dev/cmd/cgo#hdr-Passing_pointers https://pkg.go.dev/cmd/cgo#hdr-Passing_pointers https://pkg.go.dev/runtime#Pinner https://pkg.go.dev/runtime#Pinner I think it's also worth pointing out that the main Go implementation has a non-moving GC (at this time), and all kinds of fecal matter may impact a rotary ventilation device if and when that changes. Like, are we supposed to pin byte arrays we pass to syscalls? Nobody does that, right now, for short-living calls.