hotspot-gc-dev Digest, Vol 198, Issue 56

Thu Dec 28 11:59:52 UTC 2023

Hi Thomas
Thank you very much for your suggestions. Increasing G1HeapRegionSize really helped me.
I successfully reproduce the To-space Exausted with the attached file. I also attached the gclog. Here's my java version and cmds:

openjdk version "11.0.18" 2023-01-17

OpenJDK Runtime Environment Temurin-11.0.18+10 (build 11.0.18+10)

OpenJDK 64-Bit Server VM Temurin-11.0.18+10 (build 11.0.18+10, mixed mode)

java -Xmn1g -Xmx4g -Xms4g -Xlog:gc,gc+heap,gc+region*:gc.log:tags -XX:+UseG1GC -XX:G1HeapRegionSize=1M -XX:MaxTenuringThreshold=1  TospaceExaustedReproduce

I also tried java-21.0.1 but  can not reproduce it again. I'm still wondering whether it's a bug in JDK11 or not.

Thanks!
Xialin.Liu

Original

From:"hotspot-gc-dev-request"< hotspot-gc-dev-request at openjdk.org >;

Date:2023/12/21 21:26

To:"hotspot-gc-dev"< hotspot-gc-dev at openjdk.org >;

Subject:hotspot-gc-dev Digest, Vol 198, Issue 56

Send hotspot-gc-dev mailing list submissions to
	hotspot-gc-dev at openjdk.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://mail.openjdk.org/mailman/listinfo/hotspot-gc-dev
or, via email, send a message with subject or body 'help' to
	hotspot-gc-dev-request at openjdk.org

You can reach the person managing the list at
	hotspot-gc-dev-owner at openjdk.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of hotspot-gc-dev digest..."

Today's Topics:

   1. G1GC (=?utf-8?B?5YqJ5L+g6bqf?=)
   2. Re: G1GC (Thomas Schatzl)
   3. Re: RFR: 8319548: Unexpected internal name for Filler array
      klass causes error in VisualVM (Thomas Schatzl)
   4. Integrated: 8319548: Unexpected internal name for Filler
      array klass causes error in VisualVM (Thomas Schatzl)
   5. Re: RFR: 8293623: Simplify G1ConcurrentRefineThreadControl
      [v11] (Thomas Schatzl)
   6. Re: RFR: 8322539: Parallel: Remove duplicated methods in
      PSAdaptiveSizePolicy (Thomas Schatzl)

----------------------------------------------------------------------

Message: 1
Date: Thu, 21 Dec 2023 15:35:15 +0800
From: "=?utf-8?B?5YqJ5L+g6bqf?=" <1245502106 at qq.com>
To: "=?utf-8?B?aG90c3BvdC1nYy1kZXY=?=" 
Subject: G1GC
Message-ID: <tencent_11AFDC8345729F09C6ED28A270A64F34EA09 at qq.com>
Content-Type: text/plain; charset="utf-8"

When using G1GC with jdk11u, I met some cases that g1gc failed to work well and seriously affected the Java application. Here are some details:

With objs promoted to old generation, as well as some humongous objs allocated, the old generation usage exceeds the threshold indicated by IHOP.

G1GC startups concurrent marking.

Concurrent marking is finished, but the Eden is not full and mixed GC can not be triggered.

Humongous objs keep being alllocated and finally cause a to-space exausted.

Eventually, G1 triggers a Full GC for collecting all objs.

I've met plenty of cases which act the same as I described below. I'm confused that it looks like a wrong prediction for old generation growing. Is it fixed in higher JDK version? Or what should I do to deal with such problems. Looking forward to your reply!
Thanks!

???
beef.liu at qq.com

???
1245502106 at qq.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

------------------------------

Message: 2
Date: Thu, 21 Dec 2023 09:51:22 +0100
From: Thomas Schatzl 
To: hotspot-gc-dev at openjdk.org
Subject: Re: G1GC
Message-ID: <ec93e3d1-4c01-4e2c-95c5-b8d1ab497998 at oracle.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

Hi,

On 21.12.23 08:35, ??? wrote:
> When using G1GC with jdk11u, I met some cases that g1gc failed to work 
> well and seriously affected the Java application. Here are some details:
> 
>  1. With objs promoted to old generation, as well as some humongous objs
>     allocated, the old generation usage exceeds the threshold indicated
>     by IHOP.
>  2. G1GC startups concurrent marking.
>  3. Concurrent marking is finished, but the Eden is not full and mixed
>     GC can not be triggered.
>  4. Humongous objs keep being alllocated and finally cause a to-space
>     exausted.
>  5. Eventually, G1 triggers a Full GC for collecting all objs.
> 
> 
> I've met plenty of cases which act the same as I described below. I'm 
> confused that it looks like a wrong prediction for old generation 
> growing. Is it fixed in higher JDK version? Or what should I do to deal 
> with such problems. Looking forward to your reply!
> Thanks!

   thanks for your problem report.

Trying out later JDK versions is always a good idea, as there have been 
numerous improvements also to humongous object handling since JDK 11, 
but I am not sure this will fix the issue.

Without logs it is hard to say what exactly the reason for the failure 
could be, and whether the (overall) allocation rate/live set size simply 
exceeds what g1 can handle or not.

One option, without increasing heap size, that works with all JDK 
versions is to reduce the amount of humongous objects by increasing the 
region size via the -XX:G1HeapRegionSize option. Just start with 
doubling it (you can get the current value by starting with 
-XX:+PrintFlagsFinal) and see what works.

Do you happen to be able to provide a small reproducer?

Hth,
   Thomas

------------------------------

Message: 3
Date: Thu, 21 Dec 2023 09:20:47 GMT
From: Thomas Schatzl 
To: , 
Subject: Re: RFR: 8319548: Unexpected internal name for Filler array
	klass causes error in VisualVM
Message-ID:
	<DmSvGcogfrzfe7cYGWAiPN3DZ2LnxVkWqZXuL3FFdu8=.c77cd491-16c1-422b-af07-3372acbebc6d at github.com>

Content-Type: text/plain; charset=utf-8

On Tue, 19 Dec 2023 10:59:09 GMT, Albert Mingkun Yang  wrote:

>> Hi all,
>> 
>>   please review this change that changes the filler array class name (again) after user feedback.
>> 
>> In particular, the previous name `Ljdk/internal/vm/FillerArray;` confuses some tools (https://github.com/oracle/visualvm/issues/523). I.e. it's not an array, but still variable sized.
>> This change adds the `[` array bracket, and renames the element name to not have `Array` inside to not try to pretend that the element is some other kind of array.
>> 
>> Testing: tier1-6
>> 
>> Thanks,
>>   Thomas
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @dholmes-ora for your reviews

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17155#issuecomment-1865916220

------------------------------

Message: 4
Date: Thu, 21 Dec 2023 09:20:49 GMT
From: Thomas Schatzl 
To: , 
Subject: Integrated: 8319548: Unexpected internal name for Filler
	array klass causes error in VisualVM
Message-ID:
	<coI9BJsR5JSjH106doGp9HfjoIMWAZtmFXiB1fc2ncI=.c8eceac4-da33-4132-a18d-876e5caef7c0 at github.com>

Content-Type: text/plain; charset=utf-8

On Tue, 19 Dec 2023 10:08:14 GMT, Thomas Schatzl  wrote:

> Hi all,
> 
>   please review this change that changes the filler array class name (again) after user feedback.
> 
> In particular, the previous name `Ljdk/internal/vm/FillerArray;` confuses some tools (https://github.com/oracle/visualvm/issues/523). I.e. it's not an array, but still variable sized.
> This change adds the `[` array bracket, and renames the element name to not have `Array` inside to not try to pretend that the element is some other kind of array.
> 
> Testing: tier1-6
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 05745e3f
Author:    Thomas Schatzl 
URL:       https://git.openjdk.org/jdk/commit/05745e3f1d56f71d7647e81fa5933c9f4ed18430
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8319548: Unexpected internal name for Filler array klass causes error in VisualVM

Co-authored-by: Tom?? H?rka 
Reviewed-by: ayang, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/17155

------------------------------

Message: 5
Date: Thu, 21 Dec 2023 12:49:49 GMT
From: Thomas Schatzl 
To: 
Subject: Re: RFR: 8293623: Simplify G1ConcurrentRefineThreadControl
	[v11]
Message-ID:
	<_csq-Wj-Xx9pZHnCdKvErTUcigQQTmfah4L3PIJindQ=.5ee4bbbc-e377-4dd6-9019-3ae6a62728ef at github.com>

Content-Type: text/plain; charset=utf-8

On Tue, 19 Dec 2023 15:11:20 GMT, Lei Zaakjyu  wrote:

>> 8293623: Simplify G1ConcurrentRefineThreadControl
>
> Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix

lgtm

-------------

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17077#pullrequestreview-1792902478

------------------------------

Message: 6
Date: Thu, 21 Dec 2023 13:26:39 GMT
From: Thomas Schatzl 
To: 
Subject: Re: RFR: 8322539: Parallel: Remove duplicated methods in
	PSAdaptiveSizePolicy
Message-ID:
	<zhjpzwiZGciBHl6rPB8mi6p62fPzXoMNTXNSgdAq1Ug=.9af70ba7-40a7-48d6-9856-be2e04edc446 at github.com>

Content-Type: text/plain; charset=utf-8

On Wed, 20 Dec 2023 10:56:46 GMT, Albert Mingkun Yang  wrote:

> Trivial removing duplicate code.

Marked as reviewed by tschatzl (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17167#pullrequestreview-1792967653

End of hotspot-gc-dev Digest, Vol 198, Issue 56
***********************************************

劉俠麟
1245502106 at qq.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20231228/764669db/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TospaceExaustedReproduce.java
Type: application/octet-stream
Size: 2859 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20231228/764669db/TospaceExaustedReproduce-0001.java>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gc.log
Type: application/octet-stream
Size: 2692 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20231228/764669db/gc-0001.log>