3 ms·
Heap caches that keep things longer than a GC cycle are terrible under GC unless you have a collector in the new style like ZGC, Azul or Shenandoah.
by spullara 7y ago
Heap caches that keep things longer than a GC cycle are terrible under GC unless you have a collector in the new style like ZGC, Azul or Shenandoah.
- deleted 7y ago[deleted]
- sitkack 7y agoSystems with poor GC and the need to keep data for lifetimes greater than a request should have an easy to use off heap mechanism to prevent these problems. Often something like Redis is used as a shared cache that is invisible to the garbage collector, there is a natural key with a weak reference (by name) into a KV store. One could embed a KV store into an application that the GC can't scan into.
- spullara 7y ago100%. In Java, you would often use OpenHFT's ChronicleMap for now and hopefully inline classes/records in Java 16 or so.
- cgh 7y agoEhcache has an efficient off-heap store: https://github.com/Terracotta-OSS/offheap-store/ https://github.com/Terracotta-OSS/offheap-store/ Doesn't Go have something like this available? It's an obvious thing for garbage-collected languages to have.
- mappu 7y agoYou can usually resort to `import C` and using `C.malloc` to get an unsafe.Pointer.
- mappu 7y agoWhat feature of "the new style" makes them more suitable in this case?
- spullara 7y agoThey have very short pause times even for very large heaps with lots of objects in them as they don't have to crawl the entire live tree when collecting.