> the term "pauseless" was in fact invented precisely because of people like you, who abused the original terms

This language seems unnecessarily personal and accusatory.

I put "pauseless" in quotes because I know it's not entirely pauseless. It's described as "ultra low pause time" by the original project.

However, whether we like it or not, Azul has established the term "pauseless" as the way to describe their own collector which before Shenandoah was the only GC that can realistically be described that way, and which Shenandoah is very similar to. This is despite the fact that Zing still pauses. Specifically, the GC moves objects whilst the program runs.

I am unaware of any GC algorithms that are truly, completely pauseless in every situation. So I don't know what you want the term to be reserved for.

The question is what sort of pauses do you care about. I don't know about Shenandoah but the original Pauseless GC that Azul developed (and the current C4 on x86) have smaller GC pause times then thread switches.

So, if you are operating in a environment where you don't care about thread switching, you might also not care about GC anymore.

You are correct however, its not pauseless, that just a marketing term.

AFAIK Azul is pauseless - it never "stops the world". Sure, it stops each thread (that's pretty much required for any synchronization mechanism, especially if you also need to determine the thread's roots), but it never stops all threads at once ("the world").

It never stops the world for full heap collection, but there is a synchronization point where all threads have to check in. This is the only thing required, so you have GC pauses, just really, really small ones. That's why I said, that practically, GC pauses are no longer relevant.

That's not correct. Unless it changed recently, Zing still has safe points as it's basically a fork of HotSpot and HotSpot pauses programs for all kinds of reasons beyond GC.

There's a talk on YouTube where they discuss their work to drive down safe point pause times. They eventually made the pauses so fast it hardly matters, but it wasn't technically completely pauseless.

Yes, Azul's C4 paper states that they do use some "synchronisation" stop-the-world phases (although their previous GCs that had hardware/kernel read barriers might not have), but IIRC Doligez-Leroy GC doesn't (although I'm not sure it was ever properly implemented).

On the other hand, Shenandoah has an explicit synchronisation phase in its algorithm (not sure if that's a fundamental property of the algorithm or just a JVM limitation though). From [0] (that was 2 years ago, things might have improved since, but I can't find a more recent version).

> Pauses only long enough to scan root set

[0]: https://rkennke.files.wordpress.com/2014/02/shenandoahtake4....

They had synchronization points on the hardware platform as well. The difference is that they had some amount of hardware support that made the thread check-in extremely fast.

I think Zing has always had safe points.

Calling a GC that does much of its work while not-blocking-your-code seems like an appropriate use of the word "concurrent". Concurrent almost never implies "will never block", as far as I've seen people use it. If anything, that would be a "lock-free concurrent GC" or something.

Has he GP edited his comment? "Pauseless" in quotes seems to suggest recognition that the GC is not truely pauseless. I interpretted the comment as being in contrast to Go's GC, which also purports to be very low pause.

No, it had quotes from the start.

GC must also reallocate used memory to avoid fragmentation of free memory. Do you know a true fully pauseless algorithm for that?

Downvoters - WTF? Memory fragmentation is the problem for long standing processes with frequent allocations/deallocations of various sizes.

http://stackoverflow.com/questions/3770457/what-is-memory-fr...

IIRC Azul's pauseless GC uses kernel-level memory barriers to catch accesses to recently moved objects.

Azul still have pauses (10-100ms).

> Azul Systems has built a custom system (CPU, chip, board, and OS) specifically to run garbage collected virtual machines. The custom CPU includes a read barrier instruction. The read barrier enables a highly concurrent, parallel and compacting GC algorithm. The Pauseless GC algorithm is simple, efficient (low mutator overhead), and has no Stop-The-World pauses.

Azul is very similar to Shenandoah we are talking about. Updating of a wrong pointer still needs time, which can be unlucky when write trap is triggered in the middle of moving of large object.

It's the "stop-the-world" pauses that are problematic and that we've been talking about. Single-thread pauses are a fact of life, completely unavoidable with any dynamic memory allocation system even without GC (e.g. when malloc searches the free-lists).