> The standard JVM garbage collection strategy is “stop the world.”
This is quite an over-simplification for what is a fundamental property to think about when designing a performance-oriented system.
The default collector in HotSpot does, I think, stop the world when collecting. But it also does multiple small collections between larger major collections. It, by default, optimizes for throughput over latency since most applications care more about overall throughput than low latency.
Even with the default, you can tune the maximum latency if you want to sacrifice throughput:
I specifically came here to write something very similar. Thank you. Call me a JVM fanboy, but when I see such comments, I tend to believe the author didn't want to spend time genuinely understanding the JVM and doing thorough testing.
I don't want to discard per-actor heap memory in Pony. That's pretty slick. Pony has been on my radar for a while because it does a lot of things well.
Depends on the sizing I believe. One problem I see in Java-based DB like Cassandra and Elasticsearch is JVM busy doing garbage collection. The major collection kicks in all the time. Probably because of bad config and bad data usage pattern, but it is still a common problem for me. I am all ears for advice.
This was an anti-pattern of the runtime model that Java inherited from Smalltalk. Tuning the GC used to be an arcane art. There was also a lot of effort put in by programming shops to just reducing GC pressure as an optimization. This is why I appreciate Golang's pragmatic approach of not using the GC by avoiding the heap. The main benefit to having GC is to make initial development faster by reducing the severity and frequency of mistakes. It's really there as a safety net, not as a foolproof end-all be-all. Use tools in a way which plays up their strengths.
It's hard to tune a GC to be super-fast. It's easy to profile and find your biggest memory leaks.
How much free space is there after a collection? The garbage collector benefits a lot from having enough extra free space to keep things with medium lifetimes in the first generation.
The issue I observed was the both gen filled out very quickly so there was no chance for the minor to complete and just skip to major. But because the gens are consistently filled up, the JVM became "locked" doing full GC.
The default collector in HotSpot does, I think, stop the world when collecting. But it also does multiple small collections between larger major collections. It, by default, optimizes for throughput over latency since most applications care more about overall throughput than low latency.
Even with the default, you can tune the maximum latency if you want to sacrifice throughput:
https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gc...
Not only that, but HotSpot also features a true concurrent collector, which is a command-line flag away.