Fork me on GitHub
#announcements
<
2019-05-07
>
alexyakushev10:05:40

Maybe #announcements is the wrong place for this, but I've written a detailed post about our experience with Shenandoah GC: http://clojure-goes-fast.com/blog/shenandoah-in-production/ Hope you enjoy!

pez10:05:58

I think it fits here. 😃 And there is also #news-and-articles

mkvlr10:05:15

nice, thanks for sharing. Unfortunately it looks like it won’t be supported by oracle and we’d like to switch to Graal VM for the polyglot support so we can’t use it but it looks really impressive.

vemv11:05:18

> the application as a whole, not only the GC phase, is slower with Shenandoah GC which specific resource gets restrained? (e.g. CPU)

damienstanton11:05:32

@ I believe that's due to the concurrent sweeps i.e. that you must pay the latency cost during GC passes, even though they're individually small. I work at a Go shop and there are a lot of similarities between Go's mark & sweep GC and Shenandoah. One makes the same trade-off with throughput.

alexyakushev12:05:00

This is because Shenandoah uses forwarding pointers and memory barriers for each object field access. It must do that so that compaction (relocation) can happen concurrently with the application.

justalanm14:05:28

The second scicloj meeting will take place next week! https://twitter.com/scicloj/status/1118828437597192192