Some questions about garbage collector

What is the actual concern, then?

From my experience on different systems with highload, I did not see effects, that could point to think about it. 

Echoing what Vic and Dmitry have mentioned.  GARCOL cleans up large KILLs, so it's a database operation.  Your post seems to ask a different question, akin to Java object garbage collection. 

I've been quite surprised to see how much work gets done by IRIS processes with scant process memory; I suppose because it's so easy to use globals.

Understanding what you are experiencing and trying to do would help a lot.

1) Is there a garbage collector per process or global?

In Java Garbage Collection, the GC runs per JVM process. Each JVM has its own heap memory divided into regions (Young Generation, Old Generation, Metaspace, etc.), and the garbage collector operates only on that JVM’s memory. It does not share heap space across multiple JVM processes.

So, if you run multiple JVM processes (say multiple microservices), each process has its own garbage collector managing memory independently.

In IRIS, based on your mention of gmheap and per-process allocations, it looks like memory management is split between per-process memory and shared global memory. While IRIS does not rely on Java’s GC directly, the concept is somewhat similar: process-local allocations are cleaned up when a process ends, and shared memory has its own reclamation strategy.

2) Does garbage collection block other processes?

In Java Garbage Collection, yes — some collectors introduce “Stop-the-World” (STW) pauses, which suspend all application threads briefly while GC work is done. Traditional collectors like Serial GC and Parallel GC are more prone to STW events.

However, modern collectors (like G1 GC, ZGC, and Shenandoah) aim to minimize or almost eliminate global pauses by running GC work concurrently with the application.

In IRIS, depending on how memory cleanup is implemented, if there is any shared-memory cleanup, it might involve synchronization that impacts other processes. But for per-process allocations, cleanup would generally be localized.

3) Can you gather GC metrics?

In Java Garbage Collection, absolutely. The JVM exposes a wide range of metrics through:

• JMX (Java Management Extensions) – to monitor GC count, duration, memory pools.
• Garbage Collector logs (-Xlog:gc* in newer JVMs) – to track GC cycles, pause times, etc.
• Profilers and tools like JVisualVM, JConsole, and external APM tools (e.g., Prometheus + Grafana, New Relic, etc.).

In IRIS, unless explicitly documented, GC-like information may not be directly exposed. You may need to look for IRIS-specific utilities or monitoring hooks to get cleanup stats.

Summary as a Java Architect

• Java Garbage Collection is always per JVM process, never global across processes.
• GC can block application threads during STW phases, though modern collectors reduce this impact.
• JVM provides extensive GC monitoring and logging capabilities for performance tuning.

For InterSystems IRIS, memory management is different from Java GC. If you’re interested in GC-like metrics inside IRIS, I’d recommend checking if IRIS offers system monitoring hooks or shared memory cleanup statistics in its management portal.