4 ms·

My understanding is that global variables in Go are not garbage collected. Is that true? If so then is this not creating the cache struct as a global var and th

• hu3 7y ago
  The struct pointer itself wont be GC'd. It's intentional as the cache should be up for as long as the server process runs. However, that struct contains data that can and will be GC'd once no longer used. This is the type of the variable: https://github.com/allegro/bigcache/blob/master/bigcache.go https://github.com/allegro/bigcache/blob/master/bigcache.go
  • lainga 7y ago
    The mantra I'm always told around slices is "Don't keep pointer slices. Don't keep pointer slices." Because the entire thing will fail escape analysis and go onto the heap. But it's OK in this case, right? Because, as you say, the BigCache (including the []*cacheShard) is allocated once; never gets GC'd; and it's around forever.
• KirinDave 7y ago
  Caches keep data, they don't delete them. It makes sense that a low latency cache would always keep the root of its cache structure in memory.
  • thephyber 7y ago
    > Caches keep data, they don't delete them. To be accurate, caches both keep and delete data. In fact, deleting data is a pretty important function of most caches as the nature of a cache is a fast lookup, not an infinite store.
    • KirinDave 7y ago
      This is of course a glib statement, but in general cached have specific (often configurable) eviction policies, so we would expect to see the root of the cache held perpetually anyways.