Comment by sanxiyn | Hacker News Reader

Comment by sanxiyn | Hacker News Reader

Parent Full thread

I wouldn't say impossible, but yes, there are reasons this is difficult to fix in Go compared to Java and C#, and intentionally so.

Quoting from http://talks.golang.org/2012/splash.article (emphasis mine):

"To give the programmer this flexibility, Go must support what we call interior pointers to objects allocated in the heap. The X.buf field in the example above lives within the struct but it is legal to capture the address of this inner field, for instance to pass it to an I/O routine. In Java, as in many garbage-collected languages, it is not possible to construct an interior pointer like this, but in Go it is idiomatic. This design point affects which collection algorithms can be used, and may make them more difficult, but after careful thought we decided that it was necessary to allow interior pointers because of the benefits to the programmer and the ability to reduce pressure on the (perhaps harder to implement) collector."

To be fair I don't think this is a blocker for Go to implement GGC and CGC. .NET supports interior pointers too, for example. You just have to design your allocator right to allow the card marking to work.

In practice I think that the biggest problems are compiler related and affect both Go and Rust. Go and Rust both use conservative GC on the stack and as a result they take a lot of shortcuts. For example, LLVM (and GCC as far as I'm aware, though someone like DannyBee may correct me here) loses the distinction between integers and pointers by the time they get to the machine instruction level, which makes a lot of optimizations easier to implement but also making it impossible to generate precise stack maps. Fixing this would be a lot of hard work. It's probably easier in the Plan 9 compilers, of course, though I suspect it's still going to be a lot of hard work.

I've been following along on golang-dev, and they seem to be making progress on precise stacks.

See https://groups.google.com/forum/?fromgroups#!topic/golang-de... for example.

You know a lot more about these things than I do.

That said: Aren't the equivalent pointers in .Net _only_ allowed/usable if you pin your object? If you tell the GC explicitly 'please don't move that, I'm pointing to that thing here'?

That's hard to bolt on to Go, imho. For Go it seems to be implicitly allowed, in .Net you have to ask explicitly?

Go's GC is non-moving, exactly because they can't precisely know what a pointer is and what is just some random int.

So it's basically as if all objects are pinned in Go. I don't expect that to change. There are probably tons of Go code out there which will break in response to a change.

I guess it will be pushed back to some mystical "2.0" release, along with Generics.

Reply on news.ycombinator.com