Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


Systems 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.


100%. In Java, you would often use OpenHFT's ChronicleMap for now and hopefully inline classes/records in Java 16 or so.


Ehcache has an efficient off-heap 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.


You can usually resort to `import C` and using `C.malloc` to get an unsafe.Pointer.


What feature of "the new style" makes them more suitable in this case?


They 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: