JDK-8293861 : G1: Disable preventive GCs by default
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 17,20
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2022-09-15
  • Updated: 2023-11-13
  • Resolved: 2022-09-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 20
20 b16Fixed
Related Reports
Relates :  
JDK-8297639 - Remove preventive GCs in G1
Sub Tasks
JDK-8293863 :  
Release Note: G1: Disable Preventive GCs by Default - Resolved
Description
JDK-8257774 added "preventive" garbage collections in G1: speculative garbage collections added to avoid costly evacuation failures due to allocation bursts filling up the heap quickly.

These preventive garbage collections have some issues: the main issue is that it's an additional gc:

* object aging is based on number of gcs, so additional gcs cause premature promotion
* more promotion means more mixed gc phases
* additional, potentially unnecessary gc pause

This is somewhat compounded by that the current prediction to trigger preventive garbage collections is very conservative, triggering preventive garbage collections too often and too early.

As we have gathered experience with this feature, we found that in many cases it is a net loss - particularly since its introduction the reason for existing, evacuation failures, got extremely fast (e.g. JDK-8256265).

At this point the suggestion is to disable this feature by default. In the future it might be completely removed.
Comments
The disabling and subsequent removal of preventive GC has caused issues for Elasticsearch, when running with JDK 20 and 21. The particular scenario that encounters problems is one where hundreds of documents are retrieved from a search, each with a large(ish) 4MB size. These documents comprise a ~400 MB pytorch model being transfered from a data node to an ML (Machine Learning) node. The pytorch model is chunked and stored in separate documents that are retrieved one at a time by the ML node. When repeatedly allocating these large arrays, we see memory pressure distinctly increase in JDK 20.0.1. For JDK 20.x we set -XX:+G1UsePreventiveGC. For JDK 21, since no such flag is available, we obviously do not it, but the behaviour is slightly better ( GC exhibit's slightly better behaviour, but not as good as JDK 20 with the aforementioned flag ). Elasticsearch endeavours to workaround this issue, by 1) reducing the size of the chunks to say 1MB, and 2) reusing the memory backed by the arrays for subsequent chunks. See https://github.com/elastic/elasticsearch/issues/99592 for further details. ( there are many other related issues with Elasticsearch, but this one is the most relevant and coherent ).
13-11-2023
Thanks. I'll remove the tag for now, feel free to add it again if you feel more urgence.
03-10-2023
This has impacted TrinoDB https://github.com/trinodb/trino/pull/15380, but we don't have other data to share. You're right that this could help some, but hurt others. I'm going to close my PR right now. But I'm going to see if there is more evidence that supports this backport and reopen if needed.
28-09-2023
[17u] I don't think this is a good candidate for backport. 1) Existing installations are tailored for the current gc tuning of 17. Changing this might help some, others can see a regression. 2) The reasoning for this change mentions. JDK-8256265. That is not in 17. 3) There is a flag, so a simple workaround is available.
27-09-2023
Fix request (17u) Not a clean backport due to neighboring changes in the same file. Patch is simple and manual fixes are trivial.
25-09-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/1758 Date: 2023-09-20 23:18:00 +0000
20-09-2023
I am seeing the same problem with 17. In the cases I saw, preventive GC promoted objects to old gen without making much progress and eventually triggered full GC.
24-10-2022
Changeset: d7c1a763 Author: Thomas Schatzl <tschatzl@openjdk.org> Date: 2022-09-19 07:29:01 +0000 URL: https://git.openjdk.org/jdk/commit/d7c1a7635d3437b91fba358e8682b4a56a65d826
19-09-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/10304 Date: 2022-09-16 10:49:21 +0000
16-09-2022