From duke at openjdk.java.net Thu Dec 2 23:40:03 2021 From: duke at openjdk.java.net (David Alvarez) Date: Thu, 2 Dec 2021 23:40:03 GMT Subject: RFR: Make use of nanoseconds for GC times Message-ID: In multiple places for hotspot management the resolution used for times is milliseconds. With new collectors getting into sub-millisecond pause times, this resolution is not enough. This change moves internal values in LastGcStat to use milliseconds. GcInfo is still reporting the values in milliseconds for compatibility reasons ------------- Commit messages: - Make use of nanoseconds for GC times Changes: https://git.openjdk.java.net/shenandoah/pull/102/files Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=102&range=00 Stats: 35 lines in 6 files changed: 28 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/shenandoah/pull/102.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/102/head:pull/102 PR: https://git.openjdk.java.net/shenandoah/pull/102 From duke at openjdk.java.net Fri Dec 3 00:01:56 2021 From: duke at openjdk.java.net (David Alvarez) Date: Fri, 3 Dec 2021 00:01:56 GMT Subject: RFR: Make use of nanoseconds for GC times [v2] In-Reply-To: References: Message-ID: > In multiple places for hotspot management the resolution used for times is milliseconds. With new collectors getting into sub-millisecond pause times, this resolution is not enough. > > This change moves internal values in LastGcStat to use milliseconds. GcInfo is still reporting the values in milliseconds for compatibility reasons David Alvarez has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Make use of nanoseconds for GC times ------------- Changes: - all: https://git.openjdk.java.net/shenandoah/pull/102/files - new: https://git.openjdk.java.net/shenandoah/pull/102/files/584cd487..e446234b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=102&range=01 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=102&range=00-01 Stats: 7 lines in 2 files changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/shenandoah/pull/102.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/102/head:pull/102 PR: https://git.openjdk.java.net/shenandoah/pull/102 From wkemper at openjdk.java.net Fri Dec 3 18:47:01 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Fri, 3 Dec 2021 18:47:01 GMT Subject: RFR: Only verify last object start for marked objects Message-ID: <_ZY5GCp95Rp2kVjyVqUBpj3YLLH974_sLDk_FIdPZpg=.d48bc48b-fb01-4296-8644-40b169fafd2d@github.com> In some cases, verification could invoke `size` on an unmarked object resulting in a crash. ------------- Commit messages: - Only verify last object start for marked objects Changes: https://git.openjdk.java.net/shenandoah/pull/103/files Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=103&range=00 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/shenandoah/pull/103.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/103/head:pull/103 PR: https://git.openjdk.java.net/shenandoah/pull/103 From kdnilsen at openjdk.java.net Fri Dec 3 20:27:32 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Fri, 3 Dec 2021 20:27:32 GMT Subject: RFR: Only verify last object start for marked objects In-Reply-To: <_ZY5GCp95Rp2kVjyVqUBpj3YLLH974_sLDk_FIdPZpg=.d48bc48b-fb01-4296-8644-40b169fafd2d@github.com> References: <_ZY5GCp95Rp2kVjyVqUBpj3YLLH974_sLDk_FIdPZpg=.d48bc48b-fb01-4296-8644-40b169fafd2d@github.com> Message-ID: On Fri, 3 Dec 2021 18:40:14 GMT, William Kemper wrote: > In some cases, verification could invoke `size` on an unmarked object resulting in a crash. src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp line 402: > 400: max_offset = CardTable::card_size_in_words; > 401: } > 402: size_t prev_offset = offset; Is this change motivated by a detected bug, or is this just a "style" improvement? It looks to me like this change is equivalent to the original code, because in both cases (when !ctx and ctx), we unconditionally set prev_offset to offset in the first iteration of the do-while loop. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/103 From wkemper at openjdk.java.net Fri Dec 3 21:56:33 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Fri, 3 Dec 2021 21:56:33 GMT Subject: RFR: Only verify last object start for marked objects In-Reply-To: References: <_ZY5GCp95Rp2kVjyVqUBpj3YLLH974_sLDk_FIdPZpg=.d48bc48b-fb01-4296-8644-40b169fafd2d@github.com> Message-ID: On Fri, 3 Dec 2021 20:24:09 GMT, Kelvin Nilsen wrote: >> In some cases, verification could invoke `size` on an unmarked object resulting in a crash. > > src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp line 402: > >> 400: max_offset = CardTable::card_size_in_words; >> 401: } >> 402: size_t prev_offset = offset; > > Is this change motivated by a detected bug, or is this just a "style" improvement? It looks to me like this change is equivalent to the original code, because in both cases (when !ctx and ctx), we unconditionally set prev_offset to offset in the first iteration of the do-while loop. Unconditionally setting prev_offset in the second branch (i.e., when `ctx` is not null) _is_ the bug. If the code there sets prev_offset to refer to refer to an _unmarked_ object, the following verification check to get the `size` on an unmarked object could crash. The intention here was to make sure that `prev_offset` never refers to an unmarked object, but this change isn't enough to guarantee that. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/103 From wkemper at openjdk.java.net Fri Dec 3 22:39:10 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Fri, 3 Dec 2021 22:39:10 GMT Subject: RFR: Only verify last object start for marked objects [v2] In-Reply-To: <_ZY5GCp95Rp2kVjyVqUBpj3YLLH974_sLDk_FIdPZpg=.d48bc48b-fb01-4296-8644-40b169fafd2d@github.com> References: <_ZY5GCp95Rp2kVjyVqUBpj3YLLH974_sLDk_FIdPZpg=.d48bc48b-fb01-4296-8644-40b169fafd2d@github.com> Message-ID: > In some cases, verification could invoke `size` on an unmarked object resulting in a crash. William Kemper has updated the pull request incrementally with one additional commit since the last revision: Explicitly track last marked object when verifying last object start ------------- Changes: - all: https://git.openjdk.java.net/shenandoah/pull/103/files - new: https://git.openjdk.java.net/shenandoah/pull/103/files/81e1eb0b..566d24c1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=103&range=01 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=103&range=00-01 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/shenandoah/pull/103.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/103/head:pull/103 PR: https://git.openjdk.java.net/shenandoah/pull/103 From kdnilsen at openjdk.java.net Mon Dec 6 19:53:51 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Mon, 6 Dec 2021 19:53:51 GMT Subject: RFR: Only verify last object start for marked objects [v2] In-Reply-To: References: <_ZY5GCp95Rp2kVjyVqUBpj3YLLH974_sLDk_FIdPZpg=.d48bc48b-fb01-4296-8644-40b169fafd2d@github.com> Message-ID: On Fri, 3 Dec 2021 22:39:10 GMT, William Kemper wrote: >> In some cases, verification could invoke `size` on an unmarked object resulting in a crash. > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Explicitly track last marked object when verifying last object start Marked as reviewed by kdnilsen (Committer). ------------- PR: https://git.openjdk.java.net/shenandoah/pull/103 From kdnilsen at openjdk.java.net Mon Dec 6 19:53:54 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Mon, 6 Dec 2021 19:53:54 GMT Subject: RFR: Only verify last object start for marked objects [v2] In-Reply-To: References: <_ZY5GCp95Rp2kVjyVqUBpj3YLLH974_sLDk_FIdPZpg=.d48bc48b-fb01-4296-8644-40b169fafd2d@github.com> Message-ID: On Fri, 3 Dec 2021 21:53:07 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp line 402: >> >>> 400: max_offset = CardTable::card_size_in_words; >>> 401: } >>> 402: size_t prev_offset = offset; >> >> Is this change motivated by a detected bug, or is this just a "style" improvement? It looks to me like this change is equivalent to the original code, because in both cases (when !ctx and ctx), we unconditionally set prev_offset to offset in the first iteration of the do-while loop. > > Unconditionally setting prev_offset in the second branch (i.e., when `ctx` is not null) _is_ the bug. If the code there sets prev_offset to refer to refer to an _unmarked_ object, the following verification check to get the `size` on an unmarked object could crash. The intention here was to make sure that `prev_offset` never refers to an unmarked object, but this change isn't enough to guarantee that. Thanks for clarifying. Looks good to me as now drafted. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/103 From wkemper at openjdk.java.net Mon Dec 6 20:18:46 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Mon, 6 Dec 2021 20:18:46 GMT Subject: Integrated: Only verify last object start for marked objects In-Reply-To: <_ZY5GCp95Rp2kVjyVqUBpj3YLLH974_sLDk_FIdPZpg=.d48bc48b-fb01-4296-8644-40b169fafd2d@github.com> References: <_ZY5GCp95Rp2kVjyVqUBpj3YLLH974_sLDk_FIdPZpg=.d48bc48b-fb01-4296-8644-40b169fafd2d@github.com> Message-ID: On Fri, 3 Dec 2021 18:40:14 GMT, William Kemper wrote: > In some cases, verification could invoke `size` on an unmarked object resulting in a crash. This pull request has now been integrated. Changeset: 58064aa5 Author: William Kemper URL: https://git.openjdk.java.net/shenandoah/commit/58064aa5f604fb07d66eb0b3fe673da377fa6b17 Stats: 6 lines in 1 file changed: 3 ins; 1 del; 2 mod Only verify last object start for marked objects Reviewed-by: kdnilsen ------------- PR: https://git.openjdk.java.net/shenandoah/pull/103 From zgu at openjdk.java.net Wed Dec 8 20:17:10 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 8 Dec 2021 20:17:10 GMT Subject: RFR: Make use of nanoseconds for GC times [v2] In-Reply-To: References: Message-ID: On Fri, 3 Dec 2021 00:01:56 GMT, David Alvarez wrote: >> In multiple places for hotspot management the resolution used for times is milliseconds. With new collectors getting into sub-millisecond pause times, this resolution is not enough. >> >> This change moves internal values in LastGcStat to use milliseconds. GcInfo is still reporting the values in milliseconds for compatibility reasons > > David Alvarez has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. I think this patch is not Shenandoah specific, should go to upstream directly. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/102 From zgu at openjdk.java.net Tue Dec 14 15:00:29 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 14 Dec 2021 15:00:29 GMT Subject: RFR: 8278767: Shenandoah: Remove unused ShenandoahRootScanner Message-ID: <2blZLKx_1lejrvoil-bwJxES_Fwwbq716rg9rPSYOJo=.468c47d0-e9f8-4cd3-98d9-43152bf63655@github.com> Please review this trivial patch that removes unused ShenandoahRootScanner class. ------------- Commit messages: - 8278767: Shenandoah: Remove unused ShenandoahRootScanner Changes: https://git.openjdk.java.net/jdk/pull/6832/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6832&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278767 Stats: 37 lines in 2 files changed: 0 ins; 37 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6832.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6832/head:pull/6832 PR: https://git.openjdk.java.net/jdk/pull/6832 From rkennke at openjdk.java.net Tue Dec 14 15:10:11 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 14 Dec 2021 15:10:11 GMT Subject: RFR: 8278767: Shenandoah: Remove unused ShenandoahRootScanner In-Reply-To: <2blZLKx_1lejrvoil-bwJxES_Fwwbq716rg9rPSYOJo=.468c47d0-e9f8-4cd3-98d9-43152bf63655@github.com> References: <2blZLKx_1lejrvoil-bwJxES_Fwwbq716rg9rPSYOJo=.468c47d0-e9f8-4cd3-98d9-43152bf63655@github.com> Message-ID: <1mx4FBiYoEu-RUv1CTS5lBKsKBNeNWdu4iiVqdsCbqU=.1be2219a-af97-4406-b3c5-7ced5d2d42d6@github.com> On Tue, 14 Dec 2021 14:19:57 GMT, Zhengyu Gu wrote: > Please review this trivial patch that removes unused ShenandoahRootScanner class. Looks good and trivial! Thanks! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6832 From zgu at openjdk.java.net Tue Dec 14 18:44:49 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 14 Dec 2021 18:44:49 GMT Subject: RFR: 8278767: Shenandoah: Remove unused ShenandoahRootScanner In-Reply-To: <1mx4FBiYoEu-RUv1CTS5lBKsKBNeNWdu4iiVqdsCbqU=.1be2219a-af97-4406-b3c5-7ced5d2d42d6@github.com> References: <2blZLKx_1lejrvoil-bwJxES_Fwwbq716rg9rPSYOJo=.468c47d0-e9f8-4cd3-98d9-43152bf63655@github.com> <1mx4FBiYoEu-RUv1CTS5lBKsKBNeNWdu4iiVqdsCbqU=.1be2219a-af97-4406-b3c5-7ced5d2d42d6@github.com> Message-ID: On Tue, 14 Dec 2021 15:06:39 GMT, Roman Kennke wrote: >> Please review this trivial patch that removes unused ShenandoahRootScanner class. > > Looks good and trivial! Thanks! Thanks, @rkennke ------------- PR: https://git.openjdk.java.net/jdk/pull/6832 From zgu at openjdk.java.net Tue Dec 14 18:44:49 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 14 Dec 2021 18:44:49 GMT Subject: Integrated: 8278767: Shenandoah: Remove unused ShenandoahRootScanner In-Reply-To: <2blZLKx_1lejrvoil-bwJxES_Fwwbq716rg9rPSYOJo=.468c47d0-e9f8-4cd3-98d9-43152bf63655@github.com> References: <2blZLKx_1lejrvoil-bwJxES_Fwwbq716rg9rPSYOJo=.468c47d0-e9f8-4cd3-98d9-43152bf63655@github.com> Message-ID: On Tue, 14 Dec 2021 14:19:57 GMT, Zhengyu Gu wrote: > Please review this trivial patch that removes unused ShenandoahRootScanner class. This pull request has now been integrated. Changeset: de65230d Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/de65230d7183eb2d534afae5891eaa27074b8a7d Stats: 37 lines in 2 files changed: 0 ins; 37 del; 0 mod 8278767: Shenandoah: Remove unused ShenandoahRootScanner Reviewed-by: rkennke ------------- PR: https://git.openjdk.java.net/jdk/pull/6832 From dchuyko at openjdk.java.net Tue Dec 14 23:18:22 2021 From: dchuyko at openjdk.java.net (Dmitry Chuyko) Date: Tue, 14 Dec 2021 23:18:22 GMT Subject: RFR: 8278826: Print error if Shenandoah flags are empty (instead of crashing) Message-ID: ShouldNotReachHere() is replaced by vm_exit_during_initialization() in few places where ShenandoahGCMode and ShenandoahGCHeuristics are examined. Generic testing: gc/shenandoah jtreg tests. ------------- Commit messages: - Replace ShouldNotReachHere by vm_exit_during_initialization Changes: https://git.openjdk.java.net/jdk/pull/6842/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6842&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278826 Stats: 5 lines in 4 files changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6842.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6842/head:pull/6842 PR: https://git.openjdk.java.net/jdk/pull/6842 From rkennke at openjdk.java.net Wed Dec 15 08:31:03 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 15 Dec 2021 08:31:03 GMT Subject: RFR: 8278826: Print error if Shenandoah flags are empty (instead of crashing) In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 23:11:46 GMT, Dmitry Chuyko wrote: > ShouldNotReachHere() is replaced by vm_exit_during_initialization() in few places where ShenandoahGCMode and ShenandoahGCHeuristics are examined. > > Generic testing: gc/shenandoah jtreg tests. How did you trigger those ShouldNotReachHere()? How can those options become NULL, if they have a default value? ------------- PR: https://git.openjdk.java.net/jdk/pull/6842 From dchuyko at openjdk.java.net Wed Dec 15 15:18:55 2021 From: dchuyko at openjdk.java.net (Dmitry Chuyko) Date: Wed, 15 Dec 2021 15:18:55 GMT Subject: RFR: 8278826: Print error if Shenandoah flags are empty (instead of crashing) In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 23:11:46 GMT, Dmitry Chuyko wrote: > ShouldNotReachHere() is replaced by vm_exit_during_initialization() in few places where ShenandoahGCMode and ShenandoahGCHeuristics are examined. > > Generic testing: gc/shenandoah jtreg tests. It is 'Flag='. Consider following command lines: java -XX:+UseShenandoahGC -XX:ShenandoahGCMode= -version java -XX:+UseShenandoahGC -XX:ShenandoahGCMode=satb -XX:ShenandoahGCHeuristics= -version java -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=iu -XX:ShenandoahGCHeuristics= -version java -XX:+UseShenandoahGC -XX:+UnlockDiagnosticVMOptions -XX:ShenandoahGCMode=passive -XX:ShenandoahGCHeuristics= -version ------------- PR: https://git.openjdk.java.net/jdk/pull/6842 From zgu at openjdk.java.net Wed Dec 15 19:20:20 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 15 Dec 2021 19:20:20 GMT Subject: RFR: 8278551: Shenandoah: Adopt WorkerThread::worker_id() to replace Shenandoah specific implementation Message-ID: Shenandoah stores worker_id in ThreadLocalData for the same purpose as JDK-8278351. After JDK-8278351, Shenandoah should adopt WorkerThread::worker_id() from JDK-8278351 to replace its own implementation. Test: - [x] hotspot_gc_shenandoah ------------- Commit messages: - 8278551: Shenandoah: Adopt WorkerThread::worker_id() to replace Shenandoah specific implementation Changes: https://git.openjdk.java.net/jdk/pull/6853/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6853&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278551 Stats: 35 lines in 4 files changed: 2 ins; 27 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/6853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6853/head:pull/6853 PR: https://git.openjdk.java.net/jdk/pull/6853 From zgu at openjdk.java.net Wed Dec 15 19:25:25 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 15 Dec 2021 19:25:25 GMT Subject: RFR: 8278551: Shenandoah: Adopt WorkerThread::worker_id() to replace Shenandoah specific implementation [v2] In-Reply-To: References: Message-ID: > Shenandoah stores worker_id in ThreadLocalData for the same purpose as JDK-8278351. > > After JDK-8278351, Shenandoah should adopt WorkerThread::worker_id() from JDK-8278351 to replace its own implementation. > > Test: > - [x] hotspot_gc_shenandoah Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Remove unused constant ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6853/files - new: https://git.openjdk.java.net/jdk/pull/6853/files/7f08ec19..92888fe5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6853&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6853&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6853/head:pull/6853 PR: https://git.openjdk.java.net/jdk/pull/6853 From zgu at openjdk.java.net Wed Dec 15 19:33:32 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 15 Dec 2021 19:33:32 GMT Subject: RFR: 8278551: Shenandoah: Adopt WorkerThread::worker_id() to replace Shenandoah specific implementation [v3] In-Reply-To: References: Message-ID: > Shenandoah stores worker_id in ThreadLocalData for the same purpose as JDK-8278351. > > After JDK-8278351, Shenandoah should adopt WorkerThread::worker_id() from JDK-8278351 to replace its own implementation. > > Test: > - [x] hotspot_gc_shenandoah Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Remove bad assertion ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6853/files - new: https://git.openjdk.java.net/jdk/pull/6853/files/92888fe5..8b9929dc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6853&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6853&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6853/head:pull/6853 PR: https://git.openjdk.java.net/jdk/pull/6853 From rkennke at openjdk.java.net Wed Dec 15 20:08:55 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 15 Dec 2021 20:08:55 GMT Subject: RFR: 8278551: Shenandoah: Adopt WorkerThread::worker_id() to replace Shenandoah specific implementation [v3] In-Reply-To: References: Message-ID: <8CRWsLdjAfNA-YF5aHm8_wySj_kyVVXDFOyGuL9uaTg=.086cdc67-0cf3-40f4-a664-95a6d7210cee@github.com> On Wed, 15 Dec 2021 19:33:32 GMT, Zhengyu Gu wrote: >> Shenandoah stores worker_id in ThreadLocalData for the same purpose as JDK-8278351. >> >> After JDK-8278351, Shenandoah should adopt WorkerThread::worker_id() from JDK-8278351 to replace its own implementation. >> >> Test: >> - [x] hotspot_gc_shenandoah > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Remove bad assertion Makes sense and looks good! Thank you! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6853 From gnu.andrew at redhat.com Thu Dec 16 00:51:19 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 16 Dec 2021 00:51:19 +0000 Subject: [RFR] [8u] 8u322-b01 Upstream Sync Message-ID: Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/root/merge.changeset Changes in aarch64-shenandoah-jdk8u322-b01: - JDK-6801613: Cross-platform pageDialog and printDialog top margin entry broken - JDK-8049348: compiler/intrinsics/bmi/verifycode tests on lzcnt and tzcnt use incorrect assumption about REXB prefix usage - JDK-8066588: javax/management/remote/mandatory/connection/RMIConnector_NPETest.java fails to compile - JDK-8069034: gc/g1/TestEagerReclaimHumongousRegionsClearMarkBits.java nightly failure - JDK-8077590: windows_i586_6.2-product-c2-runThese8_Xcomp_vm failing after win compiler upgrade - JDK-8080287: The image of BufferedImage.TYPE_INT_ARGB and BufferedImage.TYPE_INT_ARGB_PRE is blank - JDK-8140472: java/net/ipv6tests/TcpTest.java failed intermittently with java.net.BindException: Address already in use: NET_Bind - JDK-8176837: SunPKCS11 provider needs to check more details on PKCS11 Mechanism - JDK-8177393: Result of RescaleOp for 4BYTE_ABGR images may be 25% black - JDK-8177536: Avoid Apple Peer-to-Peer interfaces in networking tests - JDK-8182036: Load from initializing arraycopy uses wrong memory state - JDK-8183369: RFC unconformity of HttpURLConnection with proxy - JDK-8183543: Aarch64: C2 compilation often fails with "failed spill-split-recycle sanity check" - JDK-8187450: JNI local refs exceeds capacity warning in NetworkInterface::getAll - JDK-8187649: ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar - JDK-8190793: Httpserver does not detect truncated request body - JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit - JDK-8210058: Algorithmic Italic font leans opposite angle in Printing - JDK-8225082: Remove IdenTrust certificate that is expiring in September 2021 - JDK-8225083: Remove Google certificate that is expiring in December 2021 - JDK-8226806: [macOS 10.14] Methods of Java Robot should be called from appropriate thread - JDK-8231438: [macOS] Dark mode for the desktop is not supported - JDK-8232226: [macos 10.15] test/jdk/java/awt/color/EqualityTest/EqualityTest.java may fail - JDK-8237499: JFR: Include stack trace in the ThreadStart event - JDK-8239886: Minimal VM build fails after JDK-8237499 - JDK-8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 - JDK-8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print" - JDK-8272342: [TEST_BUG] java/awt/print/PrinterJob/PageDialogMarginTest.java catches all exceptions - JDK-8273342: Null pointer dereference in classFileParser.cpp:2817 Main issues of note: None, clean merge. diffstat for root b/.hgtags | 3 +++ 1 file changed, 3 insertions(+) diffstat for corba b/.hgtags | 3 +++ 1 file changed, 3 insertions(+) diffstat for jaxp b/.hgtags | 3 +++ 1 file changed, 3 insertions(+) diffstat for jaxws b/.hgtags | 3 +++ 1 file changed, 3 insertions(+) diffstat for langtools b/.hgtags | 3 +++ 1 file changed, 3 insertions(+) diffstat for nashorn b/.hgtags | 3 +++ 1 file changed, 3 insertions(+) diffstat for jdk a/make/data/cacerts/globalsignr2ca | 29 - a/make/data/cacerts/identrustdstx3 | 27 - a/test/java/net/MulticastSocket/JoinGroup.java | 46 - a/test/java/net/MulticastSocket/Leave.java | 46 - b/.hgtags | 3 b/src/macosx/classes/sun/lwawt/macosx/CPrinterJob.java | 44 + b/src/macosx/native/sun/awt/CRobot.m | 101 ++- b/src/macosx/native/sun/osxapp/NSApplicationAWT.m | 23 b/src/share/classes/java/awt/image/RescaleOp.java | 140 +++-- b/src/share/classes/java/lang/Thread.java | 5 b/src/share/classes/java/lang/ThreadLocal.java | 31 - b/src/share/classes/java/util/JapaneseImperialCalendar.java | 8 b/src/share/classes/jdk/internal/misc/TerminatingThreadLocal.java | 105 +++ b/src/share/classes/jdk/jfr/conf/default.jfc | 1 b/src/share/classes/jdk/jfr/conf/profile.jfc | 1 b/src/share/classes/sun/net/httpserver/ChunkedInputStream.java | 4 b/src/share/classes/sun/net/httpserver/FixedLengthInputStream.java | 4 b/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java | 7 b/src/share/classes/sun/nio/ch/Util.java | 12 b/src/share/classes/sun/nio/fs/NativeBuffers.java | 18 b/src/share/classes/sun/print/ServiceDialog.java | 4 b/src/share/classes/sun/security/pkcs11/SunPKCS11.java | 46 + b/src/share/native/sun/font/freetypeScaler.c | 39 + b/src/solaris/native/java/net/NetworkInterface.c | 10 b/src/windows/native/java/net/NetworkInterface.c | 10 b/test/com/sun/net/httpserver/bugs/TruncatedRequestBody.java | 128 ++++ b/test/java/awt/ColorClass/EqualityTest/EqualityTest.java | 78 ++ b/test/java/awt/Robot/NonEmptyErrorStream.java | 89 +++ b/test/java/awt/Window/FullWindowContentTest/FullWindowContentTest.java | 9 b/test/java/awt/font/Rotate/RotatedItalicsTest.java | 55 ++ b/test/java/awt/image/RescaleOp/ImageRescaleOpTest.java | 131 ++++ b/test/java/awt/image/RescaleOp/RescaleAlphaTest.java | 89 +++ b/test/java/awt/print/PrinterJob/ExceptionFromPrintableIsIgnoredTest.java | 134 +++++ b/test/java/awt/print/PrinterJob/PageDialogMarginTest.java | 89 +++ b/test/java/net/HttpURLConnection/HttpURLConWithProxy.java | 63 +- b/test/java/net/Inet6Address/B6206527.java | 27 - b/test/java/net/Inet6Address/B6558853.java | 39 - b/test/java/net/InetAddress/CheckJNI.java | 43 - b/test/java/net/MulticastSocket/B6427403.java | 7 b/test/java/net/MulticastSocket/JoinLeave.java | 62 ++ b/test/java/net/NetworkConfigurationProbe.java | 69 ++ b/test/java/net/NetworkInterface/Test.java | 4 b/test/java/net/Socket/LinkLocal.java | 29 - b/test/java/net/SocketPermission/SocketPermissionTest.java | 24 b/test/java/net/ipv6tests/B6521014.java | 83 +-- b/test/java/net/ipv6tests/TcpTest.java | 51 - b/test/java/net/ipv6tests/Tests.java | 7 b/test/java/nio/channels/FileChannel/TempDirectBuffersReclamation.java | 91 +++ b/test/java/util/Calendar/CalendarTestScripts/JapaneseTests.java | 4 b/test/java/util/Calendar/CalendarTestScripts/japanese/japanese_roll.cts | 44 + b/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java | 4 b/test/jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java | 90 +++ b/test/jdk/jfr/event/runtime/TestThreadStartEndEvents.java | 21 b/test/lib/testlibrary/jdk/testlibrary/NetworkConfiguration.java | 267 ++++++++++ b/test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java | 26 b/test/sun/nio/ch/TestMaxCachedBufferSize.java | 90 ++- b/test/sun/security/lib/cacerts/VerifyCACerts.java | 12 57 files changed, 2165 insertions(+), 558 deletions(-) diffstat for hotspot b/.hgtags | 3 b/make/windows/makefiles/compile.make | 3 b/src/cpu/aarch64/vm/c2_globals_aarch64.hpp | 2 b/src/cpu/x86/vm/vm_version_x86.hpp | 8 + b/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp | 10 + b/src/os_cpu/bsd_x86/vm/vm_version_bsd_x86.cpp | 23 +++- b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp | 11 + b/src/share/vm/jfr/metadata/metadata.xml | 5 b/src/share/vm/jfr/support/jfrThreadLocal.cpp | 10 + b/src/share/vm/jfr/support/jfrThreadLocal.hpp | 5 b/src/share/vm/opto/library_call.cpp | 4 b/src/share/vm/prims/jni.cpp | 12 +- b/src/share/vm/prims/jvm.cpp | 10 + b/src/share/vm/runtime/fieldDescriptor.cpp | 2 b/src/share/vm/runtime/thread.hpp | 18 ++- b/test/compiler/arraycopy/TestInitializingACLoadWithBadMem.java | 57 ++++++++++ b/test/compiler/intrinsics/bmi/verifycode/BmiIntrinsicBase.java | 21 +++ b/test/compiler/intrinsics/bmi/verifycode/LZcntTestI.java | 5 b/test/compiler/intrinsics/bmi/verifycode/LZcntTestL.java | 6 - b/test/compiler/intrinsics/bmi/verifycode/TZcntTestI.java | 5 b/test/compiler/intrinsics/bmi/verifycode/TZcntTestL.java | 7 - 21 files changed, 192 insertions(+), 35 deletions(-) Successfully built on x86, x86_64, s390 (Zero), s390x (Zero), ppc (Zero), ppc64, ppc64le, aarch32 (Zero) & aarch64. Ok to push? I've also requested the setup of 8u & 8u-dev GitHub repos for Shenandoah: https://bugs.openjdk.java.net/browse/SKARA-1290 Thanks, -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From rkennke at openjdk.java.net Thu Dec 16 10:46:58 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 16 Dec 2021 10:46:58 GMT Subject: RFR: 8278826: Print error if Shenandoah flags are empty (instead of crashing) In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 23:11:46 GMT, Dmitry Chuyko wrote: > ShouldNotReachHere() is replaced by vm_exit_during_initialization() in few places where ShenandoahGCMode and ShenandoahGCHeuristics are examined. > > Generic testing: gc/shenandoah jtreg tests. OK, makes sense, then. Thank you! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6842 From mli at openjdk.java.net Thu Dec 16 11:35:01 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Thu, 16 Dec 2021 11:35:01 GMT Subject: RFR: 8278826: Print error if Shenandoah flags are empty (instead of crashing) In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 23:11:46 GMT, Dmitry Chuyko wrote: > ShouldNotReachHere() is replaced by vm_exit_during_initialization() in few places where ShenandoahGCMode and ShenandoahGCHeuristics are examined. > > Generic testing: gc/shenandoah jtreg tests. Looks good. Seems by changing `if (ShenandoahGCHeuristics != NULL)` to `if (ShenandoahGCHeuristics == NULL)`, the trailing `return NULL;` could be removed. ------------- Marked as reviewed by mli (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6842 From dchuyko at openjdk.java.net Thu Dec 16 14:07:26 2021 From: dchuyko at openjdk.java.net (Dmitry Chuyko) Date: Thu, 16 Dec 2021 14:07:26 GMT Subject: RFR: 8278826: Print error if Shenandoah flags are empty (instead of crashing) [v2] In-Reply-To: References: Message-ID: > ShouldNotReachHere() is replaced by vm_exit_during_initialization() in few places where ShenandoahGCMode and ShenandoahGCHeuristics are examined. > > Generic testing: gc/shenandoah jtreg tests. Dmitry Chuyko has updated the pull request incrementally with one additional commit since the last revision: Flipped ShenandoahGCHeuristics null check ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6842/files - new: https://git.openjdk.java.net/jdk/pull/6842/files/5823d5dc..eb9dbf7b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6842&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6842&range=00-01 Stats: 48 lines in 3 files changed: 18 ins; 21 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/6842.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6842/head:pull/6842 PR: https://git.openjdk.java.net/jdk/pull/6842 From dchuyko at openjdk.java.net Thu Dec 16 14:07:27 2021 From: dchuyko at openjdk.java.net (Dmitry Chuyko) Date: Thu, 16 Dec 2021 14:07:27 GMT Subject: RFR: 8278826: Print error if Shenandoah flags are empty (instead of crashing) In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 23:11:46 GMT, Dmitry Chuyko wrote: > ShouldNotReachHere() is replaced by vm_exit_during_initialization() in few places where ShenandoahGCMode and ShenandoahGCHeuristics are examined. > > Generic testing: gc/shenandoah jtreg tests. Thanks. I pushed a commit that flips the condition in all 3 modes though 'return NULL;' is eliminated only in PassiveMode. ------------- PR: https://git.openjdk.java.net/jdk/pull/6842 From zgu at openjdk.java.net Thu Dec 16 15:26:59 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 16 Dec 2021 15:26:59 GMT Subject: Integrated: 8278551: Shenandoah: Adopt WorkerThread::worker_id() to replace Shenandoah specific implementation In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 19:12:28 GMT, Zhengyu Gu wrote: > Shenandoah stores worker_id in ThreadLocalData for the same purpose as JDK-8278351. > > After JDK-8278351, Shenandoah should adopt WorkerThread::worker_id() from JDK-8278351 to replace its own implementation. > > Test: > - [x] hotspot_gc_shenandoah This pull request has now been integrated. Changeset: 937126b1 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/937126b1406ff0f6ac0828310e5e09003692dcd3 Stats: 39 lines in 4 files changed: 2 ins; 31 del; 6 mod 8278551: Shenandoah: Adopt WorkerThread::worker_id() to replace Shenandoah specific implementation Reviewed-by: rkennke ------------- PR: https://git.openjdk.java.net/jdk/pull/6853 From zgu at openjdk.java.net Thu Dec 16 17:35:23 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 16 Dec 2021 17:35:23 GMT Subject: RFR: 8278627: Shenandoah: TestHeapDump test failed on ppc64le Message-ID: This intermittent failure seems to be observed only on Linux ppc64le, but it is **not** ppc specific problem. With concurrent thread stack scanning/updating, nmtehod entry barrier has to be applied prior to thread stack/code roots scanning during heap iteration, to ensure scanner only sees to-space objects. The patch also cleanup the use of `nmethod::oops_do_marking_prologue/epilogue()`, which should be used with `nmethod::oops_do_try_claim()` and closures that use the nmethod, e.g. `MarkingCodeBlobClosure`. Since `Shenandoah` switched to concurrent code root iteration, they are no longer applied. Test: The failure on Linux ppc64le is intermittent, usually sees a failure about 3 `hotspot_gc_shenandoah` runs. I have yet seen any failures after 10 runs with the patch. ------------- Commit messages: - Merge branch 'master' into JDK-8278627-codecache-ppc - Fix passive mode - Fixed using wrong API - fix - v3 - Merge branch 'master' into JDK-8278627-codecache-ppc - v2 - v1 - 8278627: Shenandoah: TestHeapDump test failed on ppc64le Changes: https://git.openjdk.java.net/jdk/pull/6864/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6864&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278627 Stats: 56 lines in 3 files changed: 23 ins; 6 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/6864.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6864/head:pull/6864 PR: https://git.openjdk.java.net/jdk/pull/6864 From mli at openjdk.java.net Fri Dec 17 01:17:29 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Fri, 17 Dec 2021 01:17:29 GMT Subject: RFR: 8278826: Print error if Shenandoah flags are empty (instead of crashing) [v2] In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 14:07:26 GMT, Dmitry Chuyko wrote: >> ShouldNotReachHere() is replaced by vm_exit_during_initialization() in few places where ShenandoahGCMode and ShenandoahGCHeuristics are examined. >> >> Generic testing: gc/shenandoah jtreg tests. > > Dmitry Chuyko has updated the pull request incrementally with one additional commit since the last revision: > > Flipped ShenandoahGCHeuristics null check Thanks for updating, still good. ------------- PR: https://git.openjdk.java.net/jdk/pull/6842 From dchuyko at openjdk.java.net Fri Dec 17 09:23:30 2021 From: dchuyko at openjdk.java.net (Dmitry Chuyko) Date: Fri, 17 Dec 2021 09:23:30 GMT Subject: Integrated: 8278826: Print error if Shenandoah flags are empty (instead of crashing) In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 23:11:46 GMT, Dmitry Chuyko wrote: > ShouldNotReachHere() is replaced by vm_exit_during_initialization() in few places where ShenandoahGCMode and ShenandoahGCHeuristics are examined. > > Generic testing: gc/shenandoah jtreg tests. This pull request has now been integrated. Changeset: 247ea71d Author: Dmitry Chuyko URL: https://git.openjdk.java.net/jdk/commit/247ea71d24a251d29d9a5179e5b773df850e7261 Stats: 50 lines in 4 files changed: 19 ins; 21 del; 10 mod 8278826: Print error if Shenandoah flags are empty (instead of crashing) Reviewed-by: rkennke, mli ------------- PR: https://git.openjdk.java.net/jdk/pull/6842 From rkennke at openjdk.java.net Fri Dec 17 15:43:26 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 17 Dec 2021 15:43:26 GMT Subject: RFR: 8278627: Shenandoah: TestHeapDump test failed In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 15:32:38 GMT, Zhengyu Gu wrote: > This intermittent failure seems to be observed only on Linux ppc64le, but it is **not** ppc specific problem. > > With concurrent thread stack scanning/updating, nmtehod entry barrier has to be applied prior to thread stack/code roots scanning during heap iteration, to ensure scanner only sees to-space objects. > > The patch also cleanup the use of `nmethod::oops_do_marking_prologue/epilogue()`, which should be used with `nmethod::oops_do_try_claim()` and closures that use the nmethod, e.g. `MarkingCodeBlobClosure`. Since `Shenandoah` switched to concurrent code root iteration, they are no longer applied. > > Test: > The failure on Linux ppc64le is intermittent, usually sees a failure about 3 `hotspot_gc_shenandoah` runs. I have yet seen any failures after 10 runs with the patch. Looks good to me. Thank you! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6864 From kilyukhin at gmail.com Mon Dec 20 04:06:12 2021 From: kilyukhin at gmail.com (Kirill Ilyukhin) Date: Mon, 20 Dec 2021 13:06:12 +0900 Subject: Uncollected garbage Message-ID: Dear Shenandoah developers, I am running a Tomcat server which uses java.awt.image to generate PNG images under a RedHat build of OpenJDK 8 with Shenandoah GC. JVM heap usage grows and the heap dump contains a lot of int[] buffers which are not referenced from any CG root. Eclipse Memory Analyzer displays them under the "unreachable_objects" tab. This does not happen when I run the server with the default garbage collector. I tried both openjdk-1.8.0.265 and openjdk-1.8.0.312. Please let me know if you need more info. VisualVM displays reference tree as follows: int[]#680 |-[0] in int[][]#74 ..|-bankdata in java.awt.image.DataBufferInt#74 ....|-dataBuffer in sun.awt.image.IntegerInterleavedRaster#74 ......|-raster in java.awt.image.BufferedImage#74 ........|-bImg in sun.awt.image.BufImgSurfaceManager#74 ..........|-surfaceManager in java.awt.image.BufferedImage#74 ............|-bImg in sun.awt.image.BufImgSurfaceManager#74 (loop to bImg in sun.awt.image.BufImgSurfaceManager#74) ............|-bufImg in sun.awt.image.BufImgSurfaceData#74 ..............|-sdDefault in sun.awt.image.BufImgSurfaceManager#74 ................|-surfaceManager in java.awt.image.BufferedImage#74 (loop to surfaceManager in java.awt.image.BufferedImage#74) ........|-bufImg in sun.awt.image.BufImgSurfaceData#74 ..........|-sdDefault in sun.awt.image.BufImgSurfaceManager#74 ............|-surfaceManager in java.awt.image.BufferedImage#74 ..............|-bImg in sun.awt.image.BufImgSurfaceManager#74 ................|-surfaceManager in java.awt.image.BufferedImage#74 (loop to surfaceManager in java.awt.image.BufferedImage#74) ..............|-bufImg in sun.awt.image.BufImgSurfaceData#74 (loop to bufImg in sun.awt.image.BufImgSurfaceData#74) |-data in java.awt.image.DataBufferInt#74 ..|-dataBuffer in sun.awt.image.IntegerInterleavedRaster#74 ....|-raster in java.awt.image.BufferedImage#74 ......|-bImg in sun.awt.image.BufImgSurfaceManager#74 ........|-surfaceManager in java.awt.image.BufferedImage#74 ..........|-bImg in sun.awt.image.BufImgSurfaceManager#74 (loop to bImg in sun.awt.image.BufImgSurfaceManager#74) ........|-bufImg in sun.awt.image.BufImgSurfaceData#74 ..........|-sdDefault in sun.awt.image.BufImgSurfaceManager#74 ............|-surfaceManager in java.awt.image.BufferedImage#74 (loop to surfaceManager in java.awt.image.BufferedImage#74) ......|-bufImg in sun.awt.image.BufImgSurfaceData#74 ........|-sdDefault in sun.awt.image.BufImgSurfaceManager#74 ..........|-surfaceManager in java.awt.image.BufferedImage#74 ............|-bImg in sun.awt.image.BufImgSurfaceManager#74 ..............|-surfaceManager in java.awt.image.BufferedImage#74 (loop to surfaceManager in java.awt.image.BufferedImage#74) ............|-bufImg in sun.awt.image.BufImgSurfaceData#74 (loop to bufImg in sun.awt.image.BufImgSurfaceData#74) |-data in sun.awt.image.IntegerInterleavedRaster#74 ..|-raster in java.awt.image.BufferedImage#74 ....|-bImg in sun.awt.image.BufImgSurfaceManager#74 ......|-surfaceManager in java.awt.image.BufferedImage#74 ........|-bImg in sun.awt.image.BufImgSurfaceManager#74 (loop to bImg in sun.awt.image.BufImgSurfaceManager#74) ........|-bufImg in sun.awt.image.BufImgSurfaceData#74 ..........|-sdDefault in sun.awt.image.BufImgSurfaceManager#74 ............|-surfaceManager in java.awt.image.BufferedImage#74 (loop to surfaceManager in java.awt.image.BufferedImage#74) ....|-bufImg in sun.awt.image.BufImgSurfaceData#74 ......|-sdDefault in sun.awt.image.BufImgSurfaceManager#74 ........|-surfaceManager in java.awt.image.BufferedImage#74 ..........|-bImg in sun.awt.image.BufImgSurfaceManager#74 ............|-surfaceManager in java.awt.image.BufferedImage#74 (loop to surfaceManager in java.awt.image.BufferedImage#74) ..........|-bufImg in sun.awt.image.BufImgSurfaceData#74 (loop to bufImg in sun.awt.image.BufImgSurfaceData#74) Thank you, Kirill From shade at redhat.com Mon Dec 20 10:23:50 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 Dec 2021 11:23:50 +0100 Subject: Uncollected garbage In-Reply-To: References: Message-ID: On 12/20/21 5:06 AM, Kirill Ilyukhin wrote: > I am running a Tomcat server which uses java.awt.image to generate PNG > images under a RedHat build of OpenJDK 8 with Shenandoah GC. JVM heap usage > grows and the heap dump contains a lot of int[] buffers which are not > referenced from any CG root. Eclipse Memory Analyzer displays them under > the "unreachable_objects" tab. This does not happen when I run the server > with the default garbage collector. Those are likely filler objects: https://shipilev.net/jvm/anatomy-quarks/5-tlabs-and-heap-parsability/ That is to say it is unlikely to be a problem: GC cycles would ignore them as garbage, and heap should be compacted. The potential problem might be region-/TLAB-waste if the actual data arrays are not fitting the regions/TLABs exactly. You might want to look into Shenandoah Visualizer to understand the workload behavior better: https://github.com/openjdk/shenandoah-visualizer -- Thanks, -Aleksey From kilyukhin at gmail.com Mon Dec 20 11:26:54 2021 From: kilyukhin at gmail.com (Kirill Ilyukhin) Date: Mon, 20 Dec 2021 20:26:54 +0900 Subject: Uncollected garbage In-Reply-To: References: Message-ID: Aleksey, The heap usage is nearly 100% , with these int[] objects occupying 87%. The JVM process consumes ~100% of CPU, most of which is GC trying to free up some memory. Does this fit into "filler objects" explanation? Thank you, Kirill On Mon, 20 Dec 2021 at 19:23, Aleksey Shipilev wrote: > On 12/20/21 5:06 AM, Kirill Ilyukhin wrote: > > I am running a Tomcat server which uses java.awt.image to generate PNG > > images under a RedHat build of OpenJDK 8 with Shenandoah GC. JVM heap > usage > > grows and the heap dump contains a lot of int[] buffers which are not > > referenced from any CG root. Eclipse Memory Analyzer displays them under > > the "unreachable_objects" tab. This does not happen when I run the server > > with the default garbage collector. > > Those are likely filler objects: > https://shipilev.net/jvm/anatomy-quarks/5-tlabs-and-heap-parsability/ > > That is to say it is unlikely to be a problem: GC cycles would ignore them > as garbage, and heap > should be compacted. The potential problem might be region-/TLAB-waste if > the actual data arrays are > not fitting the regions/TLABs exactly. You might want to look into > Shenandoah Visualizer to > understand the workload behavior better: > https://github.com/openjdk/shenandoah-visualizer > > -- > Thanks, > -Aleksey > > From shade at redhat.com Mon Dec 20 11:34:25 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 Dec 2021 12:34:25 +0100 Subject: Uncollected garbage In-Reply-To: References: Message-ID: <9136be07-7585-a5f2-2a7b-5e63198bcadf@redhat.com> On 12/20/21 12:26 PM, Kirill Ilyukhin wrote: > The heap usage is nearly 100% , with these int[] objects occupying 87%. The JVM process consumes > ~100% of CPU, most of which is GC trying to free up some memory. Does this fit into "filler objects" > explanation? Still can, if that's the waste due to misfit arrays. But 87% looks not very plausible for the waste. Show the part of the GC log where the few (futile?) GC cycles happen, if possible with -verbose:gc -XX:+PrintGCDetails? Also, try to run with: a) -XX:+UnlockDiagnosticVMOptions -XX:ShenandoahGCMode=passive b) -XX:+UnlockDiagnosticVMOptions -XX:ShenandoahGCMode=passive -XX:-ShenandoahDegeneratedGC -- Thanks, -Aleksey From rkennke at redhat.com Mon Dec 20 11:39:00 2021 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 20 Dec 2021 12:39:00 +0100 Subject: Uncollected garbage In-Reply-To: References: Message-ID: > The heap usage is nearly 100% , with these int[] objects occupying 87%. The > JVM process consumes ~100% of CPU, most of which is GC trying to free up > some memory. Does this fit into "filler objects" explanation? Hmm, no, not really. AFAIK, those image objects carry their int[] for image data, and they are accessed by native code, too. Native access to arrays pins the arrays and their containing region. It seems plausible that frequent native access to image data prevents those regions from being collected, at least as long as the region contains one live/reachable image data array. Eventually, those *should* be reclaimed. Can you post heap configuration that is printed by -verbose:gc when application starts, and also typical size of the int arrays? Thanks, Roman From kilyukhin at gmail.com Mon Dec 20 14:29:16 2021 From: kilyukhin at gmail.com (Kirill Ilyukhin) Date: Mon, 20 Dec 2021 23:29:16 +0900 Subject: Uncollected garbage In-Reply-To: References: Message-ID: Roman, Aleksey, Here is what I got at the moment. Looks like these arrays are really eventually reclaimed, but after more than an hour of high GC activity and nearly 100% CPU usage. Seems a bit late. Please see GCeasy report at https://gceasy.io/my-gc-report.jsp?p=c2hhcmVkLzIwMjEvMTIvMjAvLS1nYy4yMDIxLTEyLTExXzA5LTAzLTI5LmxvZy5nei0tMTMtOC0yMg==&channel=WEB int arrays size corresponds to PNG images size. The biggest are: 678x840 - 569,520 elements = 2,278,104 bytes 452x560 - 253,120 elements = 1,012,480 byte Please see full GC log at https://kilyukhin.github.io/gc.awt.image.log.gz I will run with -verbose:gc and get back to you later. Thank you, Kirill On Mon, 20 Dec 2021 at 20:39, Roman Kennke wrote: > > The heap usage is nearly 100% , with these int[] objects occupying 87%. > The > > JVM process consumes ~100% of CPU, most of which is GC trying to free up > > some memory. Does this fit into "filler objects" explanation? > > Hmm, no, not really. > > AFAIK, those image objects carry their int[] for image data, and they > are accessed by native code, too. Native access to arrays pins the > arrays and their containing region. It seems plausible that frequent > native access to image data prevents those regions from being collected, > at least as long as the region contains one live/reachable image data > array. Eventually, those *should* be reclaimed. > > Can you post heap configuration that is printed by -verbose:gc when > application starts, and also typical size of the int arrays? > > Thanks, > Roman > > From shade at openjdk.java.net Tue Dec 21 13:21:14 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 21 Dec 2021 13:21:14 GMT Subject: RFR: 8278627: Shenandoah: TestHeapDump test failed In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 15:32:38 GMT, Zhengyu Gu wrote: > This intermittent failure seems to be observed only on Linux ppc64le, but it is **not** ppc specific problem. > > With concurrent thread stack scanning/updating, nmtehod entry barrier has to be applied prior to thread stack/code roots scanning during heap iteration, to ensure scanner only sees to-space objects. > > The patch also cleanup the use of `nmethod::oops_do_marking_prologue/epilogue()`, which should be used with `nmethod::oops_do_try_claim()` and closures that use the nmethod, e.g. `MarkingCodeBlobClosure`. Since `Shenandoah` switched to concurrent code root iteration, they are no longer applied. > > Test: > The failure on Linux ppc64le is intermittent, usually sees a failure about 3 `hotspot_gc_shenandoah` runs. I have yet seen any failures after 10 runs with the patch. Okay, but shouldn't this be in JDK 18? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6864 From shade at redhat.com Tue Dec 21 13:30:51 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 21 Dec 2021 14:30:51 +0100 Subject: [RFR] [8u] 8u322-b01 Upstream Sync In-Reply-To: References: Message-ID: <90e6289d-798f-2658-ae2d-d06e474935bf@redhat.com> On 12/16/21 1:51 AM, Andrew Hughes wrote: > Merge changesets: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/jaxws/merge.changeset Looks trivially fine. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/jdk/merge.changeset Looks fine. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/hotspot/merge.changeset Looks fine. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/root/merge.changeset Looks trivially fine. > Ok to push? Yes. -- Thanks, -Aleksey From zgu at openjdk.java.net Tue Dec 21 13:58:14 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 21 Dec 2021 13:58:14 GMT Subject: RFR: 8278627: Shenandoah: TestHeapDump test failed In-Reply-To: References: Message-ID: On Tue, 21 Dec 2021 13:18:09 GMT, Aleksey Shipilev wrote: > Okay, but shouldn't this be in JDK 18? Yes, it should go to JDK 18 as I upgraded priority to P2. So I should close this one and fix in 18 repo, right? I am still waiting for SAP's test results. ------------- PR: https://git.openjdk.java.net/jdk/pull/6864 From shade at openjdk.java.net Tue Dec 21 14:01:15 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 21 Dec 2021 14:01:15 GMT Subject: RFR: 8278627: Shenandoah: TestHeapDump test failed In-Reply-To: References: Message-ID: <4_f7s9ZSF7eQ4ahjFOrAzeJX7z-tT8StzdpmCbCM16g=.5ee50af0-9685-4d84-83d5-f5e654d1cc0d@github.com> On Tue, 21 Dec 2021 13:55:08 GMT, Zhengyu Gu wrote: > Yes, it should go to JDK 18 as I upgraded priority to P2. So I should close this one and fix in 18 repo, right? Yes, you need to do a PR against openjdk/jdk18. ------------- PR: https://git.openjdk.java.net/jdk/pull/6864 From zgu at openjdk.java.net Tue Dec 21 15:54:18 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 21 Dec 2021 15:54:18 GMT Subject: RFR: 8278627: Shenandoah: TestHeapDump test failed In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 15:32:38 GMT, Zhengyu Gu wrote: > This intermittent failure seems to be observed only on Linux ppc64le, but it is **not** ppc specific problem. > > With concurrent thread stack scanning/updating, nmtehod entry barrier has to be applied prior to thread stack/code roots scanning during heap iteration, to ensure scanner only sees to-space objects. > > The patch also cleanup the use of `nmethod::oops_do_marking_prologue/epilogue()`, which should be used with `nmethod::oops_do_try_claim()` and closures that use the nmethod, e.g. `MarkingCodeBlobClosure`. Since `Shenandoah` switched to concurrent code root iteration, they are no longer applied. > > Test: > The failure on Linux ppc64le is intermittent, usually sees a failure about 3 `hotspot_gc_shenandoah` runs. I have yet seen any failures after 10 runs with the patch. Moved PR to jdk18. ------------- PR: https://git.openjdk.java.net/jdk/pull/6864 From zgu at openjdk.java.net Tue Dec 21 15:54:18 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 21 Dec 2021 15:54:18 GMT Subject: Withdrawn: 8278627: Shenandoah: TestHeapDump test failed In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 15:32:38 GMT, Zhengyu Gu wrote: > This intermittent failure seems to be observed only on Linux ppc64le, but it is **not** ppc specific problem. > > With concurrent thread stack scanning/updating, nmtehod entry barrier has to be applied prior to thread stack/code roots scanning during heap iteration, to ensure scanner only sees to-space objects. > > The patch also cleanup the use of `nmethod::oops_do_marking_prologue/epilogue()`, which should be used with `nmethod::oops_do_try_claim()` and closures that use the nmethod, e.g. `MarkingCodeBlobClosure`. Since `Shenandoah` switched to concurrent code root iteration, they are no longer applied. > > Test: > The failure on Linux ppc64le is intermittent, usually sees a failure about 3 `hotspot_gc_shenandoah` runs. I have yet seen any failures after 10 runs with the patch. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/6864 From zgu at openjdk.java.net Tue Dec 21 15:59:41 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 21 Dec 2021 15:59:41 GMT Subject: [jdk18] RFR: 8278627: Shenandoah: TestHeapDump test failed Message-ID: This intermittent failure seems to be observed only on Linux ppc64le, but it is **not** ppc specific problem. With concurrent thread stack scanning/updating, nmtehod entry barrier has to be applied prior to thread stack/code roots scanning during heap iteration, to ensure scanner only sees to-space objects. The patch also cleanup the use of `nmethod::oops_do_marking_prologue/epilogue()`, which should be used with `nmethod::oops_do_try_claim()` and closures that use the nmethod, e.g. `MarkingCodeBlobClosure`. Since `Shenandoah` switched to concurrent code root iteration, they are no longer applied. Test: The failure on Linux ppc64le is intermittent, usually sees a failure about 3 `hotspot_gc_shenandoah` runs. I have yet seen any failures after 10 runs with the patch. SAP tested this patch in jdk/jdk repo in nightly tests, did not see failure so far. ------------- Commit messages: - 8278627: Shenandoah: TestHeapDump test failed Changes: https://git.openjdk.java.net/jdk18/pull/56/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=56&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278627 Stats: 56 lines in 3 files changed: 23 ins; 6 del; 27 mod Patch: https://git.openjdk.java.net/jdk18/pull/56.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/56/head:pull/56 PR: https://git.openjdk.java.net/jdk18/pull/56 From shade at openjdk.java.net Tue Dec 21 17:39:22 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 21 Dec 2021 17:39:22 GMT Subject: RFR: 8278627: Shenandoah: TestHeapDump test failed In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 15:32:38 GMT, Zhengyu Gu wrote: > This intermittent failure seems to be observed only on Linux ppc64le, but it is **not** ppc specific problem. > > With concurrent thread stack scanning/updating, nmtehod entry barrier has to be applied prior to thread stack/code roots scanning during heap iteration, to ensure scanner only sees to-space objects. > > The patch also cleanup the use of `nmethod::oops_do_marking_prologue/epilogue()`, which should be used with `nmethod::oops_do_try_claim()` and closures that use the nmethod, e.g. `MarkingCodeBlobClosure`. Since `Shenandoah` switched to concurrent code root iteration, they are no longer applied. > > Test: > The failure on Linux ppc64le is intermittent, usually sees a failure about 3 `hotspot_gc_shenandoah` runs. I have yet seen any failures after 10 runs with the patch. JDK 18 PR is here: https://github.com/openjdk/jdk18/pull/56 ------------- PR: https://git.openjdk.java.net/jdk/pull/6864 From shade at openjdk.java.net Tue Dec 21 18:12:16 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 21 Dec 2021 18:12:16 GMT Subject: [jdk18] RFR: 8278627: Shenandoah: TestHeapDump test failed In-Reply-To: References: Message-ID: On Tue, 21 Dec 2021 15:49:56 GMT, Zhengyu Gu wrote: > This intermittent failure seems to be observed only on Linux ppc64le, but it is **not** ppc specific problem. > > With concurrent thread stack scanning/updating, nmtehod entry barrier has to be applied prior to thread stack/code roots scanning during heap iteration, to ensure scanner only sees to-space objects. > > The patch also cleanup the use of `nmethod::oops_do_marking_prologue/epilogue()`, which should be used with `nmethod::oops_do_try_claim()` and closures that use the nmethod, e.g. `MarkingCodeBlobClosure`. Since `Shenandoah` switched to concurrent code root iteration, they are no longer applied. > > Test: > The failure on Linux ppc64le is intermittent, usually sees a failure about 3 `hotspot_gc_shenandoah` runs. I have yet seen any failures after 10 runs with the patch. > > SAP tested this patch in jdk/jdk repo in nightly tests, did not see failure so far. Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/56 From rkennke at openjdk.java.net Tue Dec 21 18:19:16 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 21 Dec 2021 18:19:16 GMT Subject: [jdk18] RFR: 8278627: Shenandoah: TestHeapDump test failed In-Reply-To: References: Message-ID: On Tue, 21 Dec 2021 15:49:56 GMT, Zhengyu Gu wrote: > This intermittent failure seems to be observed only on Linux ppc64le, but it is **not** ppc specific problem. > > With concurrent thread stack scanning/updating, nmtehod entry barrier has to be applied prior to thread stack/code roots scanning during heap iteration, to ensure scanner only sees to-space objects. > > The patch also cleanup the use of `nmethod::oops_do_marking_prologue/epilogue()`, which should be used with `nmethod::oops_do_try_claim()` and closures that use the nmethod, e.g. `MarkingCodeBlobClosure`. Since `Shenandoah` switched to concurrent code root iteration, they are no longer applied. > > Test: > The failure on Linux ppc64le is intermittent, usually sees a failure about 3 `hotspot_gc_shenandoah` runs. I have yet seen any failures after 10 runs with the patch. > > SAP tested this patch in jdk/jdk repo in nightly tests, did not see failure so far. Marked as reviewed by rkennke (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/56 From zgu at openjdk.java.net Tue Dec 21 19:05:17 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 21 Dec 2021 19:05:17 GMT Subject: [jdk18] Integrated: 8278627: Shenandoah: TestHeapDump test failed In-Reply-To: References: Message-ID: <5tJUZtJ8nD2coYzCp1IYsohSHktgSaVZKoUclxNwREw=.a3761ee7-1c44-4974-ae2d-3ae4add485e2@github.com> On Tue, 21 Dec 2021 15:49:56 GMT, Zhengyu Gu wrote: > This intermittent failure seems to be observed only on Linux ppc64le, but it is **not** ppc specific problem. > > With concurrent thread stack scanning/updating, nmtehod entry barrier has to be applied prior to thread stack/code roots scanning during heap iteration, to ensure scanner only sees to-space objects. > > The patch also cleanup the use of `nmethod::oops_do_marking_prologue/epilogue()`, which should be used with `nmethod::oops_do_try_claim()` and closures that use the nmethod, e.g. `MarkingCodeBlobClosure`. Since `Shenandoah` switched to concurrent code root iteration, they are no longer applied. > > Test: > The failure on Linux ppc64le is intermittent, usually sees a failure about 3 `hotspot_gc_shenandoah` runs. I have yet seen any failures after 10 runs with the patch. > > SAP tested this patch in jdk/jdk repo in nightly tests, did not see failure so far. This pull request has now been integrated. Changeset: 1128674d Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk18/commit/1128674d7f3766dda8869b213e1fc629e44ea7a8 Stats: 56 lines in 3 files changed: 23 ins; 6 del; 27 mod 8278627: Shenandoah: TestHeapDump test failed Reviewed-by: shade, rkennke ------------- PR: https://git.openjdk.java.net/jdk18/pull/56 From jwilhelm at openjdk.java.net Tue Dec 21 19:59:51 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 21 Dec 2021 19:59:51 GMT Subject: RFR: Merge jdk18 Message-ID: <2qAXnV7AsRJ0Z5Of9gkLOHIACVFGRfrl3MVhJsfpSew=.b02d2da2-3ce5-497d-a979-4e602c3834be@github.com> Forwardport JDK 18 -> JDK 19 ------------- Commit messages: - Merge - 8278627: Shenandoah: TestHeapDump test failed - 8279074: ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macosx-aarch64 - 8278044: ObjectInputStream methods invoking the OIF.CFG.getSerialFilterFactory() silent about error cases. - 8278087: Deserialization filter and filter factory property error reporting under specified - 8279011: JFR: JfrChunkWriter incorrectly handles int64_t chunk size as size_t - 8274323: compiler/codegen/aes/TestAESMain.java failed with "Error: invalid offset: -1434443640" after 8273297 - 8278609: [macos] accessibility frame is misplaced on a secondary monitor on macOS - 8278413: C2 crash when allocating array of size too large - 8278970: [macos] SigningPackageTest is failed with runtime exception - ... and 9 more: https://git.openjdk.java.net/jdk/compare/f31dead6...d5d5bad9 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=6911&range=00.0 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=6911&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/6911/files Stats: 1086 lines in 80 files changed: 695 ins; 107 del; 284 mod Patch: https://git.openjdk.java.net/jdk/pull/6911.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6911/head:pull/6911 PR: https://git.openjdk.java.net/jdk/pull/6911 From jwilhelm at openjdk.java.net Tue Dec 21 22:02:00 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 21 Dec 2021 22:02:00 GMT Subject: RFR: Merge jdk18 [v2] In-Reply-To: <2qAXnV7AsRJ0Z5Of9gkLOHIACVFGRfrl3MVhJsfpSew=.b02d2da2-3ce5-497d-a979-4e602c3834be@github.com> References: <2qAXnV7AsRJ0Z5Of9gkLOHIACVFGRfrl3MVhJsfpSew=.b02d2da2-3ce5-497d-a979-4e602c3834be@github.com> Message-ID: <06_kDiLlkp6QNtnHGLkuV7TxzucQtDwRaGLnjWX0dpM=.a14aed52-214c-4723-be0c-6bf07ef3a6e0@github.com> > Forwardport JDK 18 -> JDK 19 Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits: - Merge - 8279043: Some Security Exception Messages Miss Spaces Reviewed-by: weijun - 8278793: Interpreter(x64) intrinsify Thread.currentThread() Reviewed-by: rkennke, dcubed, dholmes - 8278044: ObjectInputStream methods invoking the OIF.CFG.getSerialFilterFactory() silent about error cases. Reviewed-by: lancea, bpb - 8278087: Deserialization filter and filter factory property error reporting under specified Reviewed-by: lancea, bpb - 8278917: Use Prev Bitmap for recording evac failed objects Reviewed-by: ayang, mli, tschatzl - 8277893: Arraycopy stress tests Reviewed-by: kvn, mli - 8278893: Parallel: Remove GCWorkerDelayMillis Reviewed-by: ayang, mli - 8278953: Clarify Class.getDeclaredConstructor specification Reviewed-by: mchung, alanb - 8277100: Dynamic dump can inadvertently overwrite default CDS archive Reviewed-by: iklam, minqi, dholmes - ... and 86 more: https://git.openjdk.java.net/jdk/compare/1128674d...d5d5bad9 ------------- Changes: https://git.openjdk.java.net/jdk/pull/6911/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6911&range=01 Stats: 18631 lines in 509 files changed: 14435 ins; 3002 del; 1194 mod Patch: https://git.openjdk.java.net/jdk/pull/6911.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6911/head:pull/6911 PR: https://git.openjdk.java.net/jdk/pull/6911 From jwilhelm at openjdk.java.net Tue Dec 21 22:02:03 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 21 Dec 2021 22:02:03 GMT Subject: Integrated: Merge jdk18 In-Reply-To: <2qAXnV7AsRJ0Z5Of9gkLOHIACVFGRfrl3MVhJsfpSew=.b02d2da2-3ce5-497d-a979-4e602c3834be@github.com> References: <2qAXnV7AsRJ0Z5Of9gkLOHIACVFGRfrl3MVhJsfpSew=.b02d2da2-3ce5-497d-a979-4e602c3834be@github.com> Message-ID: On Tue, 21 Dec 2021 19:50:51 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 18 -> JDK 19 This pull request has now been integrated. Changeset: 803cb8a7 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/803cb8a76827a21fcf9e033b4ca6a777c509169b Stats: 1086 lines in 80 files changed: 695 ins; 107 del; 284 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/6911 From kilyukhin at gmail.com Mon Dec 27 01:57:42 2021 From: kilyukhin at gmail.com (Kirill Ilyukhin) Date: Mon, 27 Dec 2021 10:57:42 +0900 Subject: Uncollected garbage In-Reply-To: References: Message-ID: Roman, Aleksey, I have to accept the "filler object" explanation. I could not reproduce the issue on a test server. These int arrays keep accumulating but the memory is reclaimed when heap usage reaches 70-80%. Now the question is why did it take that long to reclaim the memory? Before a restart the JVM was running about 2 hours 20 minutes with heap usage more than 80%, including ~30 minutes with usage ~90%. Please see the GCeasy report in my previous mail. Thank you, Kirill On Mon, 20 Dec 2021 at 23:29, Kirill Ilyukhin wrote: > Roman, Aleksey, > > Here is what I got at the moment. > > Looks like these arrays are really eventually reclaimed, but after more > than an hour of high GC activity and nearly 100% CPU usage. Seems a bit > late. > Please see GCeasy report at > https://gceasy.io/my-gc-report.jsp?p=c2hhcmVkLzIwMjEvMTIvMjAvLS1nYy4yMDIxLTEyLTExXzA5LTAzLTI5LmxvZy5nei0tMTMtOC0yMg==&channel=WEB > > int arrays size corresponds to PNG images size. The biggest are: > 678x840 - 569,520 elements = 2,278,104 bytes > 452x560 - 253,120 elements = 1,012,480 byte > > Please see full GC log at https://kilyukhin.github.io/gc.awt.image.log.gz > > I will run with -verbose:gc and get back to you later. > > Thank you, > Kirill > > On Mon, 20 Dec 2021 at 20:39, Roman Kennke wrote: > >> > The heap usage is nearly 100% , with these int[] objects occupying 87%. >> The >> > JVM process consumes ~100% of CPU, most of which is GC trying to free up >> > some memory. Does this fit into "filler objects" explanation? >> >> Hmm, no, not really. >> >> AFAIK, those image objects carry their int[] for image data, and they >> are accessed by native code, too. Native access to arrays pins the >> arrays and their containing region. It seems plausible that frequent >> native access to image data prevents those regions from being collected, >> at least as long as the region contains one live/reachable image data >> array. Eventually, those *should* be reclaimed. >> >> Can you post heap configuration that is printed by -verbose:gc when >> application starts, and also typical size of the int arrays? >> >> Thanks, >> Roman >> >>