4 ms·

> the inability to tell whether some value is heap allocated or not from the type is one of my main gripes when working with Go Why is this important? The whol

> the inability to tell whether some value is heap allocated or not from the type is one of my main gripes when working with Go Why is this important? The whole point of GC is to not spend time debating this point, as long as performance is good enough

jmgao 9y ago
There's problems when you're taking a slice and storing it for a potentially long time. If the slice is actually a subslice of a super large array, the backing slice will be kept around until the subslice goes away (assuming the implementation doesn't try to be clever about things, but it probably doesn't).
- zaarn 9y ago
  If the Go compiler can't tell anything about the length of storage of a slice, it'll end up in heap. The stack is usually only used when escape analysis determines that the value does not survive the function call, atleast IIRC. Slices should be capable of being partially deallocate so long as the backing arrays are not referenced anymore.
saghm 9y ago
Normally, it isn't! Unfortunately, "good enough" is relative, and for some applications this is vitally important. I'm not trying to knock Go's performance here; from a naive standpoint, GC'ing only some pointers is better than GC'ing all of them like you have in more traditional garbage-collected languages, but it's still easier to know what exactly is being heap allocated and what isn't in a language like Java precisely because you know that all objects are on the heap. From what I've seen of low-level optimizations in Go code, it relies heavily on techniques like generating flame graphs to analyze where allocations are occurring, which IMO isn't a very good workflow, whereas in Rust you could do this much more easily by just looking at the types that are used. I don't think this approach is necessarily incompatible with garbage collection; theoretically a language like Go could have separate vector and slice types like Rust does, and I think that would make these types of optimizations much easier! (I'm also not sure why you were downvoted for asking this; it's a perfectly reasonable question)
- lmm 9y ago
  For the record, in modern JVMs with escape analysis you may find that some objects aren't actually on the heap.
  - hyperpape 9y ago
    Go also uses escape analysis, though the effects could be different because of the compilation model.
- cdoxsey 9y ago
  > I don't think this approach is necessarily incompatible with garbage collection; theoretically a language like Go could have separate vector and slice types like Rust does, and I think that would make these types of optimizations much easier! Absolutely. It's not a GC issue, it's a design issue. Adding this kind of control would make the language harder to use. Making the hard case easier to handle for experts makes the easy case harder to handle for everyone.
  - saghm 9y ago
    Yep, I definitely agree here! I think it was a reasonable choice for Go to make, I just personally prefer working with things the Rust way.
- sriram_malhar 9y ago
  I wonder if you have seen the OpenHFT project written in pure Java for high frequency trading (https://github.com/OpenHFT https://github.com/OpenHFT). Would 175 _million_ trading transactions per second on modest hardware be considered good enough? Check out the Chronicle log in the same project, that persists tens of millions of records on disk. All it takes is a basic understanding of cache architecture and of generational GC, and simple data structures.
  - littlestymaar 9y ago
    That's where the generational GC makes all the difference. Go people don't agree[1] with almost all the industry on this topic though. [1] : https://groups.google.com/forum/#!topic/golang-nuts/KJiyv2mV2pU https://groups.google.com/forum/#!topic/golang-nuts/KJiyv2mV...
littlestymaar 9y ago
Go doesn't have a generational & compacting GC (where allocation can be made really efficient: just bumping a pointer), hence heap allocation are expensive in Go (but idk the details, and maybe they're not as expensive as they are in C or Rust). Then to avoid performance penalties, you need to reduce allocations to the minimum, but since Go use escape analysis to decide whether to allocate on the heap or not, you don't have full control on what is heap-allocated or not, and avoiding allocations can be quite tricky.

jmgao 9y ago

There's problems when you're taking a slice and storing it for a potentially long time. If the slice is actually a subslice of a super large array, the backing slice will be kept around until the subslice goes away (assuming the implementation doesn't try to be clever about things, but it probably doesn't).

zaarn 9y ago
If the Go compiler can't tell anything about the length of storage of a slice, it'll end up in heap. The stack is usually only used when escape analysis determines that the value does not survive the function call, atleast IIRC. Slices should be capable of being partially deallocate so long as the backing arrays are not referenced anymore.

saghm 9y ago

Normally, it isn't! Unfortunately, "good enough" is relative, and for some applications this is vitally important. I'm not trying to knock Go's performance here; from a naive standpoint, GC'ing only some pointers is better than GC'ing all of them like you have in more traditional garbage-collected languages, but it's still easier to know what exactly is being heap allocated and what isn't in a language like Java precisely because you know that all objects are on the heap. From what I've seen of low-level optimizations in Go code, it relies heavily on techniques like generating flame graphs to analyze where allocations are occurring, which IMO isn't a very good workflow, whereas in Rust you could do this much more easily by just looking at the types that are used. I don't think this approach is necessarily incompatible with garbage collection; theoretically a language like Go could have separate vector and slice types like Rust does, and I think that would make these types of optimizations much easier! (I'm also not sure why you were downvoted for asking this; it's a perfectly reasonable question)

lmm 9y ago
For the record, in modern JVMs with escape analysis you may find that some objects aren't actually on the heap.
- hyperpape 9y ago
  Go also uses escape analysis, though the effects could be different because of the compilation model.
cdoxsey 9y ago
> I don't think this approach is necessarily incompatible with garbage collection; theoretically a language like Go could have separate vector and slice types like Rust does, and I think that would make these types of optimizations much easier! Absolutely. It's not a GC issue, it's a design issue. Adding this kind of control would make the language harder to use. Making the hard case easier to handle for experts makes the easy case harder to handle for everyone.
- saghm 9y ago
  Yep, I definitely agree here! I think it was a reasonable choice for Go to make, I just personally prefer working with things the Rust way.
sriram_malhar 9y ago
I wonder if you have seen the OpenHFT project written in pure Java for high frequency trading (https://github.com/OpenHFT https://github.com/OpenHFT). Would 175 _million_ trading transactions per second on modest hardware be considered good enough? Check out the Chronicle log in the same project, that persists tens of millions of records on disk. All it takes is a basic understanding of cache architecture and of generational GC, and simple data structures.
- littlestymaar 9y ago
  That's where the generational GC makes all the difference. Go people don't agree[1] with almost all the industry on this topic though. [1] : https://groups.google.com/forum/#!topic/golang-nuts/KJiyv2mV2pU https://groups.google.com/forum/#!topic/golang-nuts/KJiyv2mV...

littlestymaar 9y ago

Go doesn't have a generational & compacting GC (where allocation can be made really efficient: just bumping a pointer), hence heap allocation are expensive in Go (but idk the details, and maybe they're not as expensive as they are in C or Rust). Then to avoid performance penalties, you need to reduce allocations to the minimum, but since Go use escape analysis to decide whether to allocate on the heap or not, you don't have full control on what is heap-allocated or not, and avoiding allocations can be quite tricky.