Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
G1GC (usually called G1) is a region-based garbage collector that balances application throughput against stop-the-world pause goals. Start with its defaults, then use GC logs to identify a specific problem before changing flags. In Oracle’s Java SE 26 documentation, -XX:MaxGCPauseMillis=200 is the default pause-time goal—not a promise that every pause will finish within 200 milliseconds. Fixing young-generation size with options such as -Xmn can remove an important part of G1’s ability to adapt.
What G1 does, in practical terms
G1 divides the heap into same-sized regions and assigns them to the young or old generation. Young regions are used for eden and survivor space; regions holding longer-lived objects can be assigned to the old generation. Instead of waiting to reclaim the entire heap at once, G1 selects a collection set (CSet) of regions and evacuates their live objects, reclaiming the rest.
G1 does some work concurrently with application threads, but its evacuating collections and several marking stages pause the application. Concurrent work also uses CPU time that could otherwise run application code. G1 therefore trades among pause latency, throughput, heap footprint, and available processor capacity; it is not a real-time collector, and its pause target is not a hard deadline.
G1 terms you’ll see in documentation and logs
Regions, generations, and collection sets
- Heap region: A same-sized unit of the G1 heap. G1 chooses the region size ergonomically unless it is configured with
-XX:G1HeapRegionSize. - Young-only phase: A sequence of collections focused mainly on young regions. Objects that survive may be promoted to old regions.
- Collection set (CSet): The source regions selected for evacuation during a collection. G1 favors regions where it expects to reclaim useful space at an acceptable pause cost.
- Remembered set (RSet): A structure that helps G1 find references into a region without scanning the entire heap. Its card-based entries are approximate, which limits their memory cost.
Marking and mixed collections
- Concurrent Start: A young collection that also starts concurrent marking to identify live objects in the old generation.
- Remark and Cleanup: Stop-the-world stages that finish marking and prepare for reclamation.
- Space-reclamation phase, or mixed collections: A series of collections that evacuate young regions and selected old regions. G1 stops adding old regions when it judges that further reclamation is not worth the pause effort.
- SATB (Snapshot-At-The-Beginning): G1’s marking approach treats objects that were live at the start of a marking cycle as live for that cycle. As a result, objects that die during the cycle can be retained temporarily.
IHOP, humongous objects, and failure paths
- IHOP (Initiating Heap Occupancy Percent): The old-generation occupancy threshold associated with starting concurrent marking. Adaptive IHOP estimates a suitable threshold from observed marking duration and old-generation allocation.
- Humongous object: An object at least half a region in size. It occupies contiguous old-generation regions, so frequent or large humongous allocations can contribute to allocation pressure or fragmentation.
- Evacuation failure: G1 could not move one or more objects, for example because there was not enough destination space or an object was pinned. Logs can indicate the cause; repeated inability to reclaim space can lead to a Full GC.
- Full GC: G1’s fallback of stop-the-world compaction in place across the whole heap. It can be very slow.
Which G1 flags matter first?
The table reflects Oracle’s Java SE 26 tuning guide. Defaults and support can differ by JDK release and vendor build; check the documentation for the runtime you actually deploy.
| Option | What it controls | Practical guidance |
|---|---|---|
-XX:+UseG1GC |
Selects G1 explicitly. | G1 is the default in Oracle’s Java SE 26 guide, so explicit selection is usually unnecessary on that runtime. Verify the default for other versions and vendors. |
-XX:MaxGCPauseMillis |
The pause-time goal supplied to G1’s heuristics. | Oracle’s Java SE 26 documented default is 200 ms. It is a goal, not a guaranteed maximum. Consider changing it only when measurements justify a different balance. |
-Xms and -Xmx |
Initial and maximum heap sizes. | Begin with defaults; if heap sizing needs adjustment, Oracle recommends considering a maximum heap size appropriate to the workload and available memory. |
-XX:G1NewSizePercent and -XX:G1MaxNewSizePercent |
Bounds on young-generation sizing that influence pause behavior. | Use only when logs and workload measurements support constraining G1’s adaptive choices. |
-Xmn, -XX:NewSize, -XX:MaxNewSize, and -XX:NewRatio |
Fix or constrain young-generation sizing. | Avoid these when you want G1 to adjust young size to meet pause goals. A fixed or constrained young generation overrides a key adaptation mechanism. |
-XX:G1UseAdaptiveIHOP |
Enables adaptive IHOP behavior. | Adaptive IHOP is enabled by default in Oracle’s Java SE 26 guide. G1 uses observations of marking time and old-generation allocation to estimate when to begin marking. |
-XX:InitiatingHeapOccupancyPercent |
Sets the initial IHOP threshold while adaptive IHOP lacks enough observations; it is the controlling threshold when adaptive IHOP is disabled. | Do not assume this value remains the ongoing adaptive threshold. With -XX:-G1UseAdaptiveIHOP, it controls the threshold instead. |
-XX:GCPauseIntervalMillis |
Supplies a pause interval used with the maximum pause goal in G1’s minimum-mutator-utilization planning. | Confirm exact option support and spelling in your target runtime’s documentation. |
-XX:G1PeriodicGCInterval |
Lets G1 consider a collection after a long idle period to return unused committed memory. | This is an idle-period mechanism, not a general fix for high allocation or a memory leak. |
-XX:G1PeriodicGCSystemLoadThreshold |
Refines how G1 determines whether the system is idle for periodic collection. | Check operating-system support and the documentation for the target release. |
How to tune G1 without disabling its useful adaptation
- Record the runtime and limits. Capture the JDK vendor, exact version and update, heap settings, CPU and memory limits on the host or in the container, and the workload version. Defaults and flags are not necessarily identical across runtimes.
- Define the symptom. Decide whether the problem is pause latency, throughput, heap footprint, or CPU saturation. These are different objectives, and improving one can affect another.
- Collect a baseline before changing flags. For detailed logging, Oracle’s Java SE 26 tuning guide suggests starting with
-Xlog:gc*=debugand then narrowing the output to relevant tags. Inspect pause distributions and phase timings, not just an average. For detailed G1 phase timing,-Xlog:gc+phases=debugcan help locate work such as root scanning and object copying. Oracle also documents GC phase events in JFR troubleshooting material. - Keep G1’s adaptive choices available. Start with defaults. If evidence points to a pause-goal or heap-sizing issue, consider a realistic
-XX:MaxGCPauseMillisgoal or an appropriate-Xmxbefore constraining young-generation size. - Change one control at a time. Compare the same representative workload, JDK, resource limits, and outcome measures. Record the exact flags so that an apparent improvement can be attributed to a change.
- Use the logs to investigate causes. High allocation, a large live set, humongous allocations, pinned objects, and insufficient evacuation destination space can lead to different symptoms. Identify which pattern applies before selecting a control.
What to investigate when G1 is not meeting expectations
Pauses are longer than the goal
Treat -XX:MaxGCPauseMillis as guidance to G1, not a ceiling. Use phase timings to see where pause time is spent, and examine the distribution of pauses under representative load. Forcing young-generation size may reduce G1’s ability to adjust pause work, so diagnose before reaching for -Xmn or related constraints.
Old-generation pressure or a Full GC appears
Look for the events preceding the Full GC, including evacuation failures and whether G1 had enough destination space. Check whether the old-generation live set is growing, whether old regions are being reclaimed in mixed collections, and whether humongous allocations are frequent. A flag alone cannot distinguish a genuinely large live set from allocation or evacuation pressure.
Rank #2
CPU use rises or throughput falls
Concurrent GC work competes with application threads for processor time. Compare application throughput and CPU availability as well as pauses; a pause improvement is not automatically a throughput improvement. Include container or host limits in the comparison.
Committed memory stays high during idle periods
-XX:G1PeriodicGCInterval provides an idle-period mechanism for G1 to consider collection and return unused committed memory. It is not a substitute for investigating sustained allocation or a growing live set. If using -XX:G1PeriodicGCSystemLoadThreshold, verify platform support and runtime documentation.
How release changes affect G1 terminology and defaults
Version scope matters. Oracle’s Java SE 26 tuning guide documents a 200 ms default pause goal and describes G1’s current mechanics; those statements should not be silently generalized to every JDK vendor or release.
- JDK 26: Oracle reports that G1 reduces synchronization between application and GC threads, increasing application throughput. The release summary does not provide a numeric gain, workload mix, or benchmark method, so no percentage should be inferred.
- JDK 27: Oracle’s release-change page says G1 becomes the default collector in all environments, rather than only server environments. Keep that change scoped to JDK 27 and the stated Oracle release.
- JDK 9 and later: G1 became the default in JDK 9 and later. Migration guidance also records removed collector combinations and the transition to unified GC logging; do not carry obsolete CMS settings or legacy logging syntax into a current configuration without checking migration documentation.
When to compare G1 with another collector
G1 is not universally best. If considering a different collector, compare options against the same workload and operational limits rather than choosing by reputation. Useful dimensions include:
Rank #4
- Typical and tail pause latency, and whether the requirement is a soft target or a strict deadline.
- Application throughput, including CPU spent on concurrent collection.
- Heap size, live-set size, and memory available to the runtime.
- CPU availability and contention with application threads.
- Allocation rate, promotion, object-size distribution, and frequency of humongous objects.
- Runtime vendor and version, deployment limits, and the team’s ability to capture and interpret GC diagnostics.
Oracle’s current tuning guidance recommends beginning with G1 defaults and evaluating the target workload. Collector choice should follow measured goals and constraints.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsQuick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
