Not sure why you're down-voted, this is correct.

In games you have 16ms to draw billion+ triangles (etc.).

In web, you have 100ms to round-trip a request under abitarily high load (etc.)

Cases where you cannot "stop the world" at random and just "clean up garbage" are quite common in programming. And when they happen in GC'd languages, you're much worse off.

▲

Tomte 2 months ago | parent | next [-]

That's why it's good that GC algorithms that do not "stop the world" have been in production for decades now.

▲

pebal 2 months ago | parent [-]

There are none, at least not production grade.

▲

kelseyfrog 2 months ago | parent | next [-]

There are none, or you're not aware of their existence?

▲

pebal 2 months ago | parent [-]

There are no production implementations of GC algorithms that don't stop the world at all. I know this because I have some expertise in GC algorithms.

▲

kelseyfrog 2 months ago | parent [-]

I'm curious why you don't consider C4 to be production grade

▲

pebal 2 months ago | parent [-]

Azul C4 is not a pauseless GC. In the documentation it says "C4 uses a 4-stage concurrent execution mechanism that eliminates almost all stop-the-world pauses."

▲

kelseyfrog 2 months ago | parent [-]

Except the documentation says

> C4 differentiates itself from other generational garbage collectors by supporting simultaneous-generational con- currency: the different generations are collected using concurrent (non stop-the-world) mechanisms

▲

pebal 2 months ago | parent [-]

It doesn't matter at all. C4 uses STW.

	▲	kelseyfrog 2 months ago \| parent [-]
		I wish I could have learned more from this interaction than it doesn't matter.

▲

worthless-trash 2 months ago | parent | prev [-]

I have heard (and from when I investigated) erlangs GC is 'dont stop the world'.

Maybe my definition is bad though.

▲

immibis 2 months ago | parent | prev [-]

Java's ZGC claims O(1) pause time of 0.05ms.

(As with any low-pause collector, the rest of your code is uniformly slower by some percentage because it has to make sure not to step on the toes of the concurrently-running collector.)

▲

Ygg2 2 months ago | parent | next [-]

> Java's ZGC claims O(1) pause time of 0.05ms

In practice it's actually closer to 10ms for large heaps. Large being around 220 GB.

▲

riku_iki 2 months ago | parent | prev [-]

With Java, the issue is that each allocated object carries significant memory footprint, as result total memory consumption is much higher compared to C++: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

▲

igouy 2 months ago | parent [-]

The benchmarks game shows memory use with default GC settings (as a way to uncover space-time tradeoffs), mostly for tiny tiny programs that hardly use memory.

Less difference — mandelbrot, k-nucleotide, reverse-complement, regex-redux — when the task requires memory to be used.

Less with GraalVM native-image:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

	▲	riku_iki 2 months ago \| parent [-]
		> Less difference — mandelbrot, k-nucleotide, reverse-complement, regex-redux — when the task requires memory to be used. yes, I referred to benchmarks with large memory consumption, where Java still uses from 2 to 10(as in binary tree task) more memory, which is large overhead.