Why is the user program called mutator in the context of garbage collection?

Viewed 304

Many websites mentioned the fact that the user program is called mutator in the context of garbage collection. I'd like to understand why is it be named like that because the naming might imply some important thing that I don't know yet. I tried to google it but failed to get any helpful info. One of my guesses is, perhaps the user program is changing and changing the content of memory that GC needs to work on, so it's named mutator(though I can't infer any important info from this naming way). Correct me if I'm wrong, thank you.

1 Answers

The heap is constantly changing or in simple words - it is constantly "mutated". Your application is to be blamed for this, it requests new chunks of memory all the time throughout its entire lifetime.

The heap is like a graph of Objects. There are "roots" (they never change and never go away) and there are children - these are the ones that your application allocates. These "children" always move around: some are added, some are orphaned. There can be a single child or entire sub-graphs. This moving around is caused by the application itself (how you allocate Objects). If there would be no movement, the work for a GC is trivial. This is how some GC algorithms work: they stop this entire dance (also called stop-the-world event or "mutator" threads are brought to a halt) and do their thing: see what is reachable - everything else is garbage.

There are much smarter GCs they work alongside your application, strictly speaking to java for example. The mutator threads work concurrently with GC threads. Depending on the algorithm, they might do almost all their work in a concurrent fashion (ZGC and Shenandoah 2.0) or they might some of their work in a concurrent fashion (G1 for example).

Related