3 ms·

Long GC pauses caused by large collections/caches are decade long problem with no real wide spread solution so far. With Java and .NET you can resort to off-hea

Long GC pauses caused by large collections/caches are decade long problem with no real wide spread solution so far. With Java and .NET you can resort to off-heap data. Not sure if this is possible with Go.

kerkeslager 7y ago
> Long GC pauses caused by large collections/caches are decade long problem with no real wide spread solution so far. This is arguable, but the fact is that "large collections/caches" isn't Discord's situation.
dnautics 7y ago
Erlang's basically solved it (and, arguably, solved it decades ago); relevant as discord uses erlang VM in places.
- bsder 7y ago
  Erlang "solved" the problem by breaking having lots of little heaps so a GC can blast through the entire heap extremely quickly. Would that actually work in this instance? It seems like that LRU cache they're talking about is kind of large.
  - kerkeslager 7y ago
    > Would that actually work in this instance? It seems like that LRU cache they're talking about is kind of large. I can't say for sure without knowing what the contents of that heap is, but I suspect that yes, it would work. However, the reason the heaps are so small is that they're each a lightweight thread, and in Erlang, spinning up new threads is a way of life. It would be hard to overstate what a fundamentally different architecture this is.
throwaway34241 7y ago
Yes, it's not particularly difficult with Go either. The default array/list type (slices) can point to unmanaged memory so it's easy to feed unmanaged data directly into most APIs. Also you can directly use off heap objects to support interfaces and pass references to them around just like objects allocated on the Go heap. Of course there are no generics yet so doing things like re-using a custom hash table implementation will be less convenient.

3 ms·

Long GC pauses caused by large collections/caches are decade long problem with no real wide spread solution so far. With Java and .NET you can resort to off-hea

by kikimora 7y ago

kerkeslager 7y ago
> Long GC pauses caused by large collections/caches are decade long problem with no real wide spread solution so far. This is arguable, but the fact is that "large collections/caches" isn't Discord's situation.
dnautics 7y ago
Erlang's basically solved it (and, arguably, solved it decades ago); relevant as discord uses erlang VM in places.
- bsder 7y ago
  Erlang "solved" the problem by breaking having lots of little heaps so a GC can blast through the entire heap extremely quickly. Would that actually work in this instance? It seems like that LRU cache they're talking about is kind of large.
  - kerkeslager 7y ago
    > Would that actually work in this instance? It seems like that LRU cache they're talking about is kind of large. I can't say for sure without knowing what the contents of that heap is, but I suspect that yes, it would work. However, the reason the heaps are so small is that they're each a lightweight thread, and in Erlang, spinning up new threads is a way of life. It would be hard to overstate what a fundamentally different architecture this is.
throwaway34241 7y ago
Yes, it's not particularly difficult with Go either. The default array/list type (slices) can point to unmanaged memory so it's easy to feed unmanaged data directly into most APIs. Also you can directly use off heap objects to support interfaces and pass references to them around just like objects allocated on the Go heap. Of course there are no generics yet so doing things like re-using a custom hash table implementation will be less convenient.