From shade at redhat.com Mon Jan 4 08:50:24 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 Jan 2021 09:50:24 +0100 Subject: [RFR] [8u] 8u282-b02 Upstream Sync In-Reply-To: <20201218053435.GA341703@rincewind> References: <20201218053435.GA341703@rincewind> Message-ID: On 12/18/20 6:34 AM, Andrew Hughes wrote: > Merge changesets: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b02/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b02/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b02/jaxws/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b02/jdk/merge.changeset Look trivially fine. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b02/hotspot/merge.changeset Looks fine. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b02/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b02/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b02/root/merge.changeset Look trivially fine. > Ok to push? Is it still not pushed? Fine to push then. -- Thanks, -Aleksey From redestad at openjdk.java.net Mon Jan 4 11:54:38 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 4 Jan 2021 11:54:38 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v12] In-Reply-To: References: Message-ID: > This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp > > Naming is hard, but I think the following scheme is reasonable: > > - log2i: any integral type. 0-hostile > - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) > - exact_log2i: any integral type. value must be a power of two > > I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. > > Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. > > To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: > > [ RUN ] power_of_2.log2_long_micro > [ OK ] power_of_2.log2_long_micro (3581 ms) > [ RUN ] power_of_2.log2_long_small_micro > [ OK ] power_of_2.log2_long_small_micro (549 ms) > [ RUN ] power_of_2.log2i_micro > [ OK ] power_of_2.log2i_micro (259 ms) > [ RUN ] power_of_2.log2i_small_micro > [ OK ] power_of_2.log2i_small_micro (113 ms) > > I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W > > (Intending this for 17) Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 30 additional commits since the last revision: - PPC updates courtesy of @TheRealMDoerr - Merge branch 'master' into log2_template - Merge branch 'master' into log2_template - Remove use of make_unsigned, use UINT64_FORMAT_X to make sign extension stand out - With JDK-8257985 fixed, use count_trailing_zeros to implement log2i_exact - Merge branch 'master' into log2_template - Merge branch 'master' of https://github.com/openjdk/jdk into log2_template - More review comments adressed - Issue with using count_trailing_zeros with 64-bit values on 32-bit, revert and add TODO - Merge branch 'master' into log2_template - ... and 20 more: https://git.openjdk.java.net/jdk/compare/639d328c...14a903a1 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1663/files - new: https://git.openjdk.java.net/jdk/pull/1663/files/e21e1b7a..14a903a1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=10-11 Stats: 23505 lines in 980 files changed: 13975 ins; 6182 del; 3348 mod Patch: https://git.openjdk.java.net/jdk/pull/1663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1663/head:pull/1663 PR: https://git.openjdk.java.net/jdk/pull/1663 From shade at openjdk.java.net Mon Jan 4 12:02:57 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 4 Jan 2021 12:02:57 GMT Subject: RFR: 8258490: Shenandoah: Full GC does not need to remark threads and drain SATB buffers [v2] In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 19:04:09 GMT, Zhengyu Gu wrote: >> Full GC marks heap at a pause with SATB deactivated, therefore, we don't need to remark threads and drain SATB buffers during final mark phase. >> >> - [x] hotspot_gc_shenandoah > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Minor update Looks fine to me, modulo minor nit. src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 230: > 228: class ShenandoahClaimThreadClosure : public ThreadClosure { > 229: private: > 230: uintx _claim_token; Should be `const`, maybe? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1805 From redestad at openjdk.java.net Mon Jan 4 13:38:58 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 4 Jan 2021 13:38:58 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v11] In-Reply-To: <9D4pRJcX5SOTHeBxQmxM23cQYrggeIyrflF-8bemMZs=.a3458e8c-f5d0-48bb-bbdc-ee2e625d7cf8@github.com> References: <69k8Moh5KhGkjiymiWIupvM_BgMfCE5Vz6sNSMz6Mb0=.b17954a6-0130-4e3e-bccb-ceff35213867@github.com> <9D4pRJcX5SOTHeBxQmxM23cQYrggeIyrflF-8bemMZs=.a3458e8c-f5d0-48bb-bbdc-ee2e625d7cf8@github.com> Message-ID: On Thu, 17 Dec 2020 12:09:50 GMT, Martin Doerr wrote: >>> Hi Claes, >>> I noticed that you're using `log2i_exact` in ppc.ad. That's wrong, we're hitting assertions because it's not used for exact powers of 2. Please change to `log2i`. I'll test with that change. >> >> To have the same semantics as before I guess `log2i_graceful` is the better fit. I picked `log2i_exact` since the variable names suggested they were powers of two. > > You're right, looks like `log2i_exact` should be used and only braces are wrong. I'll try to fix it and get back to you. Thanks for your patience. I've merged in a patch to ppc.ad from @TheRealMDoerr that has passed testing on PPC. I'm running a few tiers of testing now with the intent of pushing this later tonight. ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From zgu at openjdk.java.net Mon Jan 4 15:17:17 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 4 Jan 2021 15:17:17 GMT Subject: RFR: 8258490: Shenandoah: Full GC does not need to remark threads and drain SATB buffers [v3] In-Reply-To: References: Message-ID: > Full GC marks heap at a pause with SATB deactivated, therefore, we don't need to remark threads and drain SATB buffers during final mark phase. > > - [x] hotspot_gc_shenandoah Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: @shade's comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1805/files - new: https://git.openjdk.java.net/jdk/pull/1805/files/602347da..acdb27e8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1805&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1805&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1805.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1805/head:pull/1805 PR: https://git.openjdk.java.net/jdk/pull/1805 From zgu at openjdk.java.net Mon Jan 4 17:45:07 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 4 Jan 2021 17:45:07 GMT Subject: RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes [v22] In-Reply-To: References: Message-ID: > This is the first part of refactoring, that aims to isolate three Shenandoah GC modes (concurrent, degenerated and full gc). > > Shenandoah started with two GC modes, concurrent and full gc, with minimal shared code, mainly in mark phase. After introducing degenerated GC, it shared quite large portion of code with concurrent GC, with the concept that degenerated GC can simply pick up remaining work of concurrent GC in STW mode. > > It was not a big problem at that time, since concurrent GC also processed roots STW. Since Shenandoah gradually moved root processing into concurrent phase, code started to diverge, that made code hard to reason and maintain. > > First step, I would like to split STW and concurrent mark, so that: > 1) Code has to special case for STW and concurrent mark. > 2) STW mark does not need to rendezvous workers between root mark and the rest of mark > 3) STW mark does not need to activate SATB barrier and drain SATB buffers. > 4) STW mark does not need to remark some of roots. > > The patch mainly just shuffles code. Creates a base class ShenandoahMark, and moved shared code (from current shenandoahConcurrentMark) into this base class. I did 'git mv shenandoahConcurrentMark.inline.hpp shenandoahMark.inline.hpp, but git does not seem to reflect that. > > A few changes: > 1) Moved task queue set from ShenandoahConcurrentMark to ShenandoahHeap. ShenandoahMark and its subclasses are stateless. Instead, mark states are maintained in task queue, mark bitmap and SATB buffers, so that they can be created on demand. > 2) Split ShenandoahConcurrentRootScanner template to ShenandoahConcurrentRootScanner and ShenandoahSTWRootScanner > 3) Split code inside op_final_mark code into finish_mark and prepare_evacuation helper functions. > 4) Made ShenandoahMarkCompact stack allocated (as well as ShenandoahConcurrentGC and ShenandoahDegeneratedGC in upcoming refactoring) Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: - Merge - Merge branch 'master' into JDK-8255019-sh-mark - Concurrent mark does not expect forwarded objects - Merge branch 'master' into JDK-8255019-sh-mark - Merge branch 'master' into JDK-8255019-sh-mark - Silent valgrind on potential memory leak - Merge branch 'master' into JDK-8255019-sh-mark - Removed ShenandoahConcurrentMark parameter from concurrent GC entry/op, etc. - Merge branch 'master' into JDK-8255019-sh-mark - Merge - ... and 19 more: https://git.openjdk.java.net/jdk/compare/d679caa2...cde20115 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1009/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1009&range=21 Stats: 1954 lines in 22 files changed: 1070 ins; 739 del; 145 mod Patch: https://git.openjdk.java.net/jdk/pull/1009.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1009/head:pull/1009 PR: https://git.openjdk.java.net/jdk/pull/1009 From iklam at openjdk.java.net Mon Jan 4 17:47:25 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 4 Jan 2021 17:47:25 GMT Subject: RFR: 8258459: Decouple gc_globals.hpp from globals.hpp [v2] In-Reply-To: References: Message-ID: <1ag_sNd7DDMPNv9uHW0HawBjASZHTRyPxGK-ekO-JXM=.eff714de-c409-4048-84c4-f817344f767a@github.com> > Currently, [globals.hpp](https://github.com/openjdk/jdk/blob/17ace8339dd8235f3811e3975d9ccc77910b0c77/src/hotspot/share/runtime/globals.hpp#L29) is including gc_globals.hpp. This exposes all the GC command-line flags to almost all cpp files. However, only about 1/3 of the cpp files would require gc_globals.hpp. > > This RFE improves modularity and HotSpot build time. > > **Review notes:** > - Please start with globals.hpp, gc_globals.hpp. > - Flags related to TLAB are frequently used by other header files. I moved these flags to a new header tlab_globals.hpp. > - Some tweaking of oop.hpp to avoid including gc_globals.hpp in this popular header file. (Otherwise gc_globals.hpp would be included by everyone). > - The other changes are just files that use GC flags. They should have included gc_globals.hpp but didn't. > > **Testing:** > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - fixed copyright year - Merge branch 'master' into 8258459-decouple-gc-globals-hpp-from-globals-hpp - comments by coleenp - fixed copyright year - 8258459: Decouple gc_globals.hpp from globals.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1797/files - new: https://git.openjdk.java.net/jdk/pull/1797/files/df618db6..ec8a3902 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1797&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1797&range=00-01 Stats: 17381 lines in 942 files changed: 9715 ins; 4698 del; 2968 mod Patch: https://git.openjdk.java.net/jdk/pull/1797.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1797/head:pull/1797 PR: https://git.openjdk.java.net/jdk/pull/1797 From iklam at openjdk.java.net Mon Jan 4 18:00:59 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 4 Jan 2021 18:00:59 GMT Subject: RFR: 8258459: Decouple gc_globals.hpp from globals.hpp [v2] In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 13:08:23 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - fixed copyright year >> - Merge branch 'master' into 8258459-decouple-gc-globals-hpp-from-globals-hpp >> - comments by coleenp >> - fixed copyright year >> - 8258459: Decouple gc_globals.hpp from globals.hpp > > src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp line 61: > >> 59: } >> 60: >> 61: size_t ThreadLocalAllocBuffer::initial_refill_waste_limit() { return desired_size() / TLABRefillWasteFraction; } > > nit: please line this up. Fixed > src/hotspot/share/oops/oop.inline.hpp line 187: > >> 185: // disjunct below to fail if the two comparands are computed across such >> 186: // a concurrent change. >> 187: assert((s == klass->oop_size(this)) || > > It might be nicer to throw the second half of this assert into the .cpp file, like > assert(s == klass->oop_size(this) || gc_has_forwarded(), "wrong array object size"); > With the special comment above it in the cpp file. Then someone has the potential to add more information if the assert fails, and that gets Universe::hpp out of the inline file (if that helps with future cleanups). I'd like to keep this PR minimal. If I change `(Universe::heap()->is_gc_active() && is_objArray() && is_forwarded() && (get_UseParallelGC() || get_UseG1GC())` to `gc_has_forwarded()`, I would also need to move the comments about `UseParallelGC and UseG1GC can change the length field of an "old copy"...`. I think that should be done in a separate PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/1797 From zgu at openjdk.java.net Mon Jan 4 18:14:03 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 4 Jan 2021 18:14:03 GMT Subject: Integrated: 8258490: Shenandoah: Full GC does not need to remark threads and drain SATB buffers In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 17:34:43 GMT, Zhengyu Gu wrote: > Full GC marks heap at a pause with SATB deactivated, therefore, we don't need to remark threads and drain SATB buffers during final mark phase. > > - [x] hotspot_gc_shenandoah This pull request has now been integrated. Changeset: f80c63b3 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/f80c63b3 Stats: 44 lines in 1 file changed: 21 ins; 15 del; 8 mod 8258490: Shenandoah: Full GC does not need to remark threads and drain SATB buffers Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/1805 From zgu at openjdk.java.net Mon Jan 4 18:22:13 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 4 Jan 2021 18:22:13 GMT Subject: RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes [v23] In-Reply-To: References: Message-ID: > This is the first part of refactoring, that aims to isolate three Shenandoah GC modes (concurrent, degenerated and full gc). > > Shenandoah started with two GC modes, concurrent and full gc, with minimal shared code, mainly in mark phase. After introducing degenerated GC, it shared quite large portion of code with concurrent GC, with the concept that degenerated GC can simply pick up remaining work of concurrent GC in STW mode. > > It was not a big problem at that time, since concurrent GC also processed roots STW. Since Shenandoah gradually moved root processing into concurrent phase, code started to diverge, that made code hard to reason and maintain. > > First step, I would like to split STW and concurrent mark, so that: > 1) Code has to special case for STW and concurrent mark. > 2) STW mark does not need to rendezvous workers between root mark and the rest of mark > 3) STW mark does not need to activate SATB barrier and drain SATB buffers. > 4) STW mark does not need to remark some of roots. > > The patch mainly just shuffles code. Creates a base class ShenandoahMark, and moved shared code (from current shenandoahConcurrentMark) into this base class. I did 'git mv shenandoahConcurrentMark.inline.hpp shenandoahMark.inline.hpp, but git does not seem to reflect that. > > A few changes: > 1) Moved task queue set from ShenandoahConcurrentMark to ShenandoahHeap. ShenandoahMark and its subclasses are stateless. Instead, mark states are maintained in task queue, mark bitmap and SATB buffers, so that they can be created on demand. > 2) Split ShenandoahConcurrentRootScanner template to ShenandoahConcurrentRootScanner and ShenandoahSTWRootScanner > 3) Split code inside op_final_mark code into finish_mark and prepare_evacuation helper functions. > 4) Made ShenandoahMarkCompact stack allocated (as well as ShenandoahConcurrentGC and ShenandoahDegeneratedGC in upcoming refactoring) Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Update copyright years ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1009/files - new: https://git.openjdk.java.net/jdk/pull/1009/files/cde20115..4b367ed6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1009&range=22 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1009&range=21-22 Stats: 23 lines in 21 files changed: 0 ins; 0 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/1009.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1009/head:pull/1009 PR: https://git.openjdk.java.net/jdk/pull/1009 From redestad at openjdk.java.net Mon Jan 4 21:26:58 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 4 Jan 2021 21:26:58 GMT Subject: Integrated: 8257815: Replace global log2 functions with efficient implementations In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 12:00:48 GMT, Claes Redestad wrote: > This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp > > Naming is hard, but I think the following scheme is reasonable: > > - log2i: any integral type. 0-hostile > - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) > - exact_log2i: any integral type. value must be a power of two > > I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. > > Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. > > To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: > > [ RUN ] power_of_2.log2_long_micro > [ OK ] power_of_2.log2_long_micro (3581 ms) > [ RUN ] power_of_2.log2_long_small_micro > [ OK ] power_of_2.log2_long_small_micro (549 ms) > [ RUN ] power_of_2.log2i_micro > [ OK ] power_of_2.log2i_micro (259 ms) > [ RUN ] power_of_2.log2i_small_micro > [ OK ] power_of_2.log2i_small_micro (113 ms) > > I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W > > (Intending this for 17) This pull request has now been integrated. Changeset: 9d160aa1 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/9d160aa1 Stats: 283 lines in 41 files changed: 75 ins; 101 del; 107 mod 8257815: Replace global log2 functions with efficient implementations Reviewed-by: kbarrett, stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From iklam at openjdk.java.net Tue Jan 5 00:20:15 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 5 Jan 2021 00:20:15 GMT Subject: RFR: 8258459: Decouple gc_globals.hpp from globals.hpp [v3] In-Reply-To: References: Message-ID: > Currently, [globals.hpp](https://github.com/openjdk/jdk/blob/17ace8339dd8235f3811e3975d9ccc77910b0c77/src/hotspot/share/runtime/globals.hpp#L29) is including gc_globals.hpp. This exposes all the GC command-line flags to almost all cpp files. However, only about 1/3 of the cpp files would require gc_globals.hpp. > > This RFE improves modularity and HotSpot build time. > > **Review notes:** > - Please start with globals.hpp, gc_globals.hpp. > - Flags related to TLAB are frequently used by other header files. I moved these flags to a new header tlab_globals.hpp. > - Some tweaking of oop.hpp to avoid including gc_globals.hpp in this popular header file. (Otherwise gc_globals.hpp would be included by everyone). > - The other changes are just files that use GC flags. They should have included gc_globals.hpp but didn't. > > **Testing:** > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: added tlab_globals.hpp to all files that use the TLAB globals ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1797/files - new: https://git.openjdk.java.net/jdk/pull/1797/files/ec8a3902..372fd801 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1797&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1797&range=01-02 Stats: 60 lines in 31 files changed: 32 ins; 7 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/1797.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1797/head:pull/1797 PR: https://git.openjdk.java.net/jdk/pull/1797 From iklam at openjdk.java.net Tue Jan 5 06:00:20 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 5 Jan 2021 06:00:20 GMT Subject: RFR: 8258459: Decouple gc_globals.hpp from globals.hpp [v4] In-Reply-To: References: Message-ID: > Currently, [globals.hpp](https://github.com/openjdk/jdk/blob/17ace8339dd8235f3811e3975d9ccc77910b0c77/src/hotspot/share/runtime/globals.hpp#L29) is including gc_globals.hpp. This exposes all the GC command-line flags to almost all cpp files. However, only about 1/3 of the cpp files would require gc_globals.hpp. > > This RFE improves modularity and HotSpot build time. > > **Review notes:** > - Please start with globals.hpp, gc_globals.hpp. > - Flags related to TLAB are frequently used by other header files. I moved these flags to a new header tlab_globals.hpp. > - Some tweaking of oop.hpp to avoid including gc_globals.hpp in this popular header file. (Otherwise gc_globals.hpp would be included by everyone). > - The other changes are just files that use GC flags. They should have included gc_globals.hpp but didn't. > > **Testing:** > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge branch 'master' into 8258459-decouple-gc-globals-hpp-from-globals-hpp - added tlab_globals.hpp to all files that use the TLAB globals - fixed copyright year - Merge branch 'master' into 8258459-decouple-gc-globals-hpp-from-globals-hpp - comments by coleenp - fixed copyright year - 8258459: Decouple gc_globals.hpp from globals.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1797/files - new: https://git.openjdk.java.net/jdk/pull/1797/files/372fd801..f68aa0ee Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1797&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1797&range=02-03 Stats: 491 lines in 60 files changed: 213 ins; 129 del; 149 mod Patch: https://git.openjdk.java.net/jdk/pull/1797.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1797/head:pull/1797 PR: https://git.openjdk.java.net/jdk/pull/1797 From iklam at openjdk.java.net Tue Jan 5 06:00:23 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 5 Jan 2021 06:00:23 GMT Subject: RFR: 8258459: Decouple gc_globals.hpp from globals.hpp [v4] In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 13:08:54 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Merge branch 'master' into 8258459-decouple-gc-globals-hpp-from-globals-hpp >> - added tlab_globals.hpp to all files that use the TLAB globals >> - fixed copyright year >> - Merge branch 'master' into 8258459-decouple-gc-globals-hpp-from-globals-hpp >> - comments by coleenp >> - fixed copyright year >> - 8258459: Decouple gc_globals.hpp from globals.hpp > > Looks good! I had a couple of minor change requests. Thanks @coleenp and @lfoltan for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/1797 From iklam at openjdk.java.net Tue Jan 5 06:00:25 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 5 Jan 2021 06:00:25 GMT Subject: Integrated: 8258459: Decouple gc_globals.hpp from globals.hpp In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 06:24:59 GMT, Ioi Lam wrote: > Currently, [globals.hpp](https://github.com/openjdk/jdk/blob/17ace8339dd8235f3811e3975d9ccc77910b0c77/src/hotspot/share/runtime/globals.hpp#L29) is including gc_globals.hpp. This exposes all the GC command-line flags to almost all cpp files. However, only about 1/3 of the cpp files would require gc_globals.hpp. > > This RFE improves modularity and HotSpot build time. > > **Review notes:** > - Please start with globals.hpp, gc_globals.hpp. > - Flags related to TLAB are frequently used by other header files. I moved these flags to a new header tlab_globals.hpp. > - Some tweaking of oop.hpp to avoid including gc_globals.hpp in this popular header file. (Otherwise gc_globals.hpp would be included by everyone). > - The other changes are just files that use GC flags. They should have included gc_globals.hpp but didn't. > > **Testing:** > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. This pull request has now been integrated. Changeset: 5ea96072 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/5ea96072 Stats: 445 lines in 127 files changed: 253 ins; 70 del; 122 mod 8258459: Decouple gc_globals.hpp from globals.hpp Reviewed-by: lfoltan, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/1797 From thartmann at openjdk.java.net Tue Jan 5 11:59:59 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 5 Jan 2021 11:59:59 GMT Subject: [jdk16] RFR: 8258393: Shenandoah: "graph should be schedulable" assert failure In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 08:20:20 GMT, Roland Westrelin wrote: > This is a shenandoah bug but the fix is in shared code. > > At barrier expansion time, we need the raw memory state for the > control at which the barrier is expanded. Before expansion, the memory > graph is traversed and memory state for each control is recorded. In > that process, if opportunities to improve the memory graph are found, > the graph is modified. In the case of the failure, a raw memory load > was assigned a call projection as control but for that control, no > memory state was recorded and the fall back is to use the call's input > memory state. As a consequence the load's memory input is updated to a > wrong memory state. This causes the assert failure. > > The call has 2 memory projections: one for the fallthrough and one for > the exception path. One projection is the memory state for the > CatchProj for the fallthrough, the other one for the CatchProj of the > exception path. For the control projection out of the call, there's no > memory state that makes sense and assigning the control projection of > the call as control for the load is the root cause of the > problem. This happens because anti-dependence analysis is too > conservative: a memory Phi that merges states from the exception and > fallthrough path is considered a dependency and that pushed the load > right after the call. > > I propose to be less conservative in anti-dependence analysis for > Phis. For a Phi, when computing the LCA, I think it's sufficient to > only consider region's inputs that we actually reach by following the > memory edges and that's what I propose here. Otherwise looks reasonable to me. test/hotspot/jtreg/gc/shenandoah/compiler/TestBadRawMemoryAfterCall.java line 26: > 24: /** > 25: * @test > 26: * Missing `@requires vm.gc.Shenandoah` test/hotspot/jtreg/gc/shenandoah/compiler/TestBadRawMemoryAfterCall.java line 2: > 1: /* > 2: * Copyright (c) 2020, Red Hat, Inc. All rights reserved. Copyright should be updated to 2021. src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp line 2465: > 2463: #ifdef ASSERT > 2464: if ((ctrl->is_Proj() && ctrl->in(0)->is_Call()) || > 2465: (ctrl->is_Catch() && ctrl->in(0)->in(0)->is_Call())){ Indentation is wrong and whitespace is missing here `))){` src/hotspot/share/opto/loopnode.cpp line 5023: > 5021: Node* in = s->in(j); > 5022: Node* r_in = r->in(j); > 5023: if (worklist.member(in) && is_dominator(early, r_in)) { Above we check for `!sctrl->is_top()`, do we need the same check for `r_in`? ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/41 From roland at openjdk.java.net Tue Jan 5 12:42:58 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Tue, 5 Jan 2021 12:42:58 GMT Subject: [jdk16] RFR: 8258393: Shenandoah: "graph should be schedulable" assert failure In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 11:54:07 GMT, Tobias Hartmann wrote: >> This is a shenandoah bug but the fix is in shared code. >> >> At barrier expansion time, we need the raw memory state for the >> control at which the barrier is expanded. Before expansion, the memory >> graph is traversed and memory state for each control is recorded. In >> that process, if opportunities to improve the memory graph are found, >> the graph is modified. In the case of the failure, a raw memory load >> was assigned a call projection as control but for that control, no >> memory state was recorded and the fall back is to use the call's input >> memory state. As a consequence the load's memory input is updated to a >> wrong memory state. This causes the assert failure. >> >> The call has 2 memory projections: one for the fallthrough and one for >> the exception path. One projection is the memory state for the >> CatchProj for the fallthrough, the other one for the CatchProj of the >> exception path. For the control projection out of the call, there's no >> memory state that makes sense and assigning the control projection of >> the call as control for the load is the root cause of the >> problem. This happens because anti-dependence analysis is too >> conservative: a memory Phi that merges states from the exception and >> fallthrough path is considered a dependency and that pushed the load >> right after the call. >> >> I propose to be less conservative in anti-dependence analysis for >> Phis. For a Phi, when computing the LCA, I think it's sufficient to >> only consider region's inputs that we actually reach by following the >> memory edges and that's what I propose here. > > src/hotspot/share/opto/loopnode.cpp line 5023: > >> 5021: Node* in = s->in(j); >> 5022: Node* r_in = r->in(j); >> 5023: if (worklist.member(in) && is_dominator(early, r_in)) { > > Above we check for `!sctrl->is_top()`, do we need the same check for `r_in`? I don't think a Region can have a top input at this point (previous IGVN should have taken care of it). ------------- PR: https://git.openjdk.java.net/jdk16/pull/41 From roland at openjdk.java.net Tue Jan 5 13:00:10 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Tue, 5 Jan 2021 13:00:10 GMT Subject: [jdk16] RFR: 8258393: Shenandoah: "graph should be schedulable" assert failure [v2] In-Reply-To: References: Message-ID: > This is a shenandoah bug but the fix is in shared code. > > At barrier expansion time, we need the raw memory state for the > control at which the barrier is expanded. Before expansion, the memory > graph is traversed and memory state for each control is recorded. In > that process, if opportunities to improve the memory graph are found, > the graph is modified. In the case of the failure, a raw memory load > was assigned a call projection as control but for that control, no > memory state was recorded and the fall back is to use the call's input > memory state. As a consequence the load's memory input is updated to a > wrong memory state. This causes the assert failure. > > The call has 2 memory projections: one for the fallthrough and one for > the exception path. One projection is the memory state for the > CatchProj for the fallthrough, the other one for the CatchProj of the > exception path. For the control projection out of the call, there's no > memory state that makes sense and assigning the control projection of > the call as control for the load is the root cause of the > problem. This happens because anti-dependence analysis is too > conservative: a memory Phi that merges states from the exception and > fallthrough path is considered a dependency and that pushed the load > right after the call. > > I propose to be less conservative in anti-dependence analysis for > Phis. For a Phi, when computing the LCA, I think it's sufficient to > only consider region's inputs that we actually reach by following the > memory edges and that's what I propose here. Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - review - test & fix ------------- Changes: https://git.openjdk.java.net/jdk16/pull/41/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=41&range=01 Stats: 114 lines in 3 files changed: 107 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jdk16/pull/41.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/41/head:pull/41 PR: https://git.openjdk.java.net/jdk16/pull/41 From thartmann at openjdk.java.net Tue Jan 5 13:05:57 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 5 Jan 2021 13:05:57 GMT Subject: [jdk16] RFR: 8258393: Shenandoah: "graph should be schedulable" assert failure [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 13:00:10 GMT, Roland Westrelin wrote: >> This is a shenandoah bug but the fix is in shared code. >> >> At barrier expansion time, we need the raw memory state for the >> control at which the barrier is expanded. Before expansion, the memory >> graph is traversed and memory state for each control is recorded. In >> that process, if opportunities to improve the memory graph are found, >> the graph is modified. In the case of the failure, a raw memory load >> was assigned a call projection as control but for that control, no >> memory state was recorded and the fall back is to use the call's input >> memory state. As a consequence the load's memory input is updated to a >> wrong memory state. This causes the assert failure. >> >> The call has 2 memory projections: one for the fallthrough and one for >> the exception path. One projection is the memory state for the >> CatchProj for the fallthrough, the other one for the CatchProj of the >> exception path. For the control projection out of the call, there's no >> memory state that makes sense and assigning the control projection of >> the call as control for the load is the root cause of the >> problem. This happens because anti-dependence analysis is too >> conservative: a memory Phi that merges states from the exception and >> fallthrough path is considered a dependency and that pushed the load >> right after the call. >> >> I propose to be less conservative in anti-dependence analysis for >> Phis. For a Phi, when computing the LCA, I think it's sufficient to >> only consider region's inputs that we actually reach by following the >> memory edges and that's what I propose here. > > Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - review > - test & fix Thanks for updating, looks good to me. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/41 From roland at openjdk.java.net Tue Jan 5 13:05:58 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Tue, 5 Jan 2021 13:05:58 GMT Subject: [jdk16] RFR: 8258393: Shenandoah: "graph should be schedulable" assert failure [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 11:57:18 GMT, Tobias Hartmann wrote: > Otherwise looks reasonable to me. Thanks for the review. I took care of your comments (except for the is_top() check that I don't think is needed). ------------- PR: https://git.openjdk.java.net/jdk16/pull/41 From roland at openjdk.java.net Tue Jan 5 13:11:02 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Tue, 5 Jan 2021 13:11:02 GMT Subject: [jdk16] Integrated: 8258393: Shenandoah: "graph should be schedulable" assert failure In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 08:20:20 GMT, Roland Westrelin wrote: > This is a shenandoah bug but the fix is in shared code. > > At barrier expansion time, we need the raw memory state for the > control at which the barrier is expanded. Before expansion, the memory > graph is traversed and memory state for each control is recorded. In > that process, if opportunities to improve the memory graph are found, > the graph is modified. In the case of the failure, a raw memory load > was assigned a call projection as control but for that control, no > memory state was recorded and the fall back is to use the call's input > memory state. As a consequence the load's memory input is updated to a > wrong memory state. This causes the assert failure. > > The call has 2 memory projections: one for the fallthrough and one for > the exception path. One projection is the memory state for the > CatchProj for the fallthrough, the other one for the CatchProj of the > exception path. For the control projection out of the call, there's no > memory state that makes sense and assigning the control projection of > the call as control for the load is the root cause of the > problem. This happens because anti-dependence analysis is too > conservative: a memory Phi that merges states from the exception and > fallthrough path is considered a dependency and that pushed the load > right after the call. > > I propose to be less conservative in anti-dependence analysis for > Phis. For a Phi, when computing the LCA, I think it's sufficient to > only consider region's inputs that we actually reach by following the > memory edges and that's what I propose here. This pull request has now been integrated. Changeset: 6775113c Author: Roland Westrelin URL: https://git.openjdk.java.net/jdk16/commit/6775113c Stats: 114 lines in 3 files changed: 107 ins; 2 del; 5 mod 8258393: Shenandoah: "graph should be schedulable" assert failure Reviewed-by: rkennke, thartmann ------------- PR: https://git.openjdk.java.net/jdk16/pull/41 From roland at openjdk.java.net Tue Jan 5 13:10:59 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Tue, 5 Jan 2021 13:10:59 GMT Subject: [jdk16] RFR: 8258393: Shenandoah: "graph should be schedulable" assert failure [v2] In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 15:31:35 GMT, Roman Kennke wrote: > As far as I can tell, the change looks good. I'm not very familiar with the code, it would be good to have somebody else check it too. > I verified that the tests that failed before are passing now and also have run some additional tests. thanks for the review and running tests. ------------- PR: https://git.openjdk.java.net/jdk16/pull/41 From zgu at openjdk.java.net Tue Jan 5 13:43:06 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 5 Jan 2021 13:43:06 GMT Subject: RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes [v24] In-Reply-To: References: Message-ID: > This is the first part of refactoring, that aims to isolate three Shenandoah GC modes (concurrent, degenerated and full gc). > > Shenandoah started with two GC modes, concurrent and full gc, with minimal shared code, mainly in mark phase. After introducing degenerated GC, it shared quite large portion of code with concurrent GC, with the concept that degenerated GC can simply pick up remaining work of concurrent GC in STW mode. > > It was not a big problem at that time, since concurrent GC also processed roots STW. Since Shenandoah gradually moved root processing into concurrent phase, code started to diverge, that made code hard to reason and maintain. > > First step, I would like to split STW and concurrent mark, so that: > 1) Code has to special case for STW and concurrent mark. > 2) STW mark does not need to rendezvous workers between root mark and the rest of mark > 3) STW mark does not need to activate SATB barrier and drain SATB buffers. > 4) STW mark does not need to remark some of roots. > > The patch mainly just shuffles code. Creates a base class ShenandoahMark, and moved shared code (from current shenandoahConcurrentMark) into this base class. I did 'git mv shenandoahConcurrentMark.inline.hpp shenandoahMark.inline.hpp, but git does not seem to reflect that. > > A few changes: > 1) Moved task queue set from ShenandoahConcurrentMark to ShenandoahHeap. ShenandoahMark and its subclasses are stateless. Instead, mark states are maintained in task queue, mark bitmap and SATB buffers, so that they can be created on demand. > 2) Split ShenandoahConcurrentRootScanner template to ShenandoahConcurrentRootScanner and ShenandoahSTWRootScanner > 3) Split code inside op_final_mark code into finish_mark and prepare_evacuation helper functions. > 4) Made ShenandoahMarkCompact stack allocated (as well as ShenandoahConcurrentGC and ShenandoahDegeneratedGC in upcoming refactoring) Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: - Merge - Update copyright years - Merge - Merge branch 'master' into JDK-8255019-sh-mark - Concurrent mark does not expect forwarded objects - Merge branch 'master' into JDK-8255019-sh-mark - Merge branch 'master' into JDK-8255019-sh-mark - Silent valgrind on potential memory leak - Merge branch 'master' into JDK-8255019-sh-mark - Removed ShenandoahConcurrentMark parameter from concurrent GC entry/op, etc. - ... and 21 more: https://git.openjdk.java.net/jdk/compare/a6c08813...b7390c08 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1009/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1009&range=23 Stats: 1982 lines in 21 files changed: 1078 ins; 753 del; 151 mod Patch: https://git.openjdk.java.net/jdk/pull/1009.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1009/head:pull/1009 PR: https://git.openjdk.java.net/jdk/pull/1009 From shade at openjdk.java.net Tue Jan 5 14:11:06 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 5 Jan 2021 14:11:06 GMT Subject: RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes [v24] In-Reply-To: References: Message-ID: <4C2MtK5jhW_yHyzDp5k5cAaguy3QlmI0T0LTKf6n978=.8599d416-5d32-40e5-ae7f-9bf5ca5b330d@github.com> On Tue, 5 Jan 2021 13:43:06 GMT, Zhengyu Gu wrote: >> This is the first part of refactoring, that aims to isolate three Shenandoah GC modes (concurrent, degenerated and full gc). >> >> Shenandoah started with two GC modes, concurrent and full gc, with minimal shared code, mainly in mark phase. After introducing degenerated GC, it shared quite large portion of code with concurrent GC, with the concept that degenerated GC can simply pick up remaining work of concurrent GC in STW mode. >> >> It was not a big problem at that time, since concurrent GC also processed roots STW. Since Shenandoah gradually moved root processing into concurrent phase, code started to diverge, that made code hard to reason and maintain. >> >> First step, I would like to split STW and concurrent mark, so that: >> 1) Code has to special case for STW and concurrent mark. >> 2) STW mark does not need to rendezvous workers between root mark and the rest of mark >> 3) STW mark does not need to activate SATB barrier and drain SATB buffers. >> 4) STW mark does not need to remark some of roots. >> >> The patch mainly just shuffles code. Creates a base class ShenandoahMark, and moved shared code (from current shenandoahConcurrentMark) into this base class. I did 'git mv shenandoahConcurrentMark.inline.hpp shenandoahMark.inline.hpp, but git does not seem to reflect that. >> >> A few changes: >> 1) Moved task queue set from ShenandoahConcurrentMark to ShenandoahHeap. ShenandoahMark and its subclasses are stateless. Instead, mark states are maintained in task queue, mark bitmap and SATB buffers, so that they can be created on demand. >> 2) Split ShenandoahConcurrentRootScanner template to ShenandoahConcurrentRootScanner and ShenandoahSTWRootScanner >> 3) Split code inside op_final_mark code into finish_mark and prepare_evacuation helper functions. >> 4) Made ShenandoahMarkCompact stack allocated (as well as ShenandoahConcurrentGC and ShenandoahDegeneratedGC in upcoming refactoring) > > Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: > > - Merge > - Update copyright years > - Merge > - Merge branch 'master' into JDK-8255019-sh-mark > - Concurrent mark does not expect forwarded objects > - Merge branch 'master' into JDK-8255019-sh-mark > - Merge branch 'master' into JDK-8255019-sh-mark > - Silent valgrind on potential memory leak > - Merge branch 'master' into JDK-8255019-sh-mark > - Removed ShenandoahConcurrentMark parameter from concurrent GC entry/op, etc. > - ... and 21 more: https://git.openjdk.java.net/jdk/compare/a6c08813...b7390c08 First read review follows. src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 161: > 159: // threads, and performance-wise it doesn't really matter. Adds about 1ms to > 160: // full-gc. > 161: { This seems to revert JDK-8258490? src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 168: > 166: while (satb_mq_set.apply_closure_to_completed_buffer(&cl)); > 167: bool do_nmethods = heap->unload_classes() && !ShenandoahConcurrentRoots::can_do_concurrent_class_unloading(); > 168: assert(!heap->has_forwarded_objects(), "Not expected"); Do you need to move this assert? src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 314: > 312: ShenandoahReferenceProcessor* rp, > 313: ShenandoahPhaseTimings::Phase phase, > 314: uint nworkers) : This indenting seems wrong? The original one was correct, I think. src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 325: > 323: ShenandoahConcurrentWorkerSession worker_session(worker_id); > 324: ShenandoahObjToScanQueue* q = _queue_set->queue(worker_id); > 325: ShenandoahMarkResolveRefsClosure cl(q, _rp); Why `ShenandoahMarkRefsClosure` -> `ShenandoahMarkResolveRefsClosure` change? src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 335: > 333: ShenandoahReferenceProcessor* rp = _heap->ref_processor(); > 334: task_queues()->reserve(workers->active_workers()); > 335: ShenandoahMarkConcurrentRootsTask task(task_queues(), rp, ShenandoahPhaseTimings::conc_mark_roots, workers->active_workers()); Excess space: `rp, ShenandoahPhaseTimings`. src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 344: > 342: uint nworkers = workers->active_workers(); > 343: task_queues()->reserve(nworkers); > 344: TaskTerminator terminator(nworkers, task_queues()); There is another `TaskTerminator` right below it, is it correct? src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp line 58: > 56: // TODO: where to put them > 57: static void update_roots(ShenandoahPhaseTimings::Phase root_phase); > 58: static void update_thread_roots(ShenandoahPhaseTimings::Phase root_phase); Sounds like these better to be shared in `ShenandoahMark`? src/hotspot/share/gc/shenandoah/shenandoahMark.cpp line 38: > 36: #include "gc/shenandoah/shenandoahUtils.hpp" > 37: #include "gc/shenandoah/shenandoahVerifier.hpp" > 38: Excess newline? src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp line 306: > 304: ShenandoahHeap* ShenandoahMark::heap() const { > 305: return _heap; > 306: } Do we really need this method? `ShenandoahHeap::heap()` is supposed to be as fast. src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp line 249: > 247: rp->set_soft_reference_policy(true); // forcefully purge all soft references > 248: > 249: Excess newline? src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp line 2: > 1: /* > 2: * Copyright (c) 2019, 2019, Red Hat, Inc. All rights reserved. Odd change: 2020 -> 2019. src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp line 81: > 79: task_queues()->reserve(nworkers); > 80: > 81: Excess new-line, drop one. src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp line 96: > 94: TASKQUEUE_STATS_ONLY(task_queues()->print_taskqueue_stats()); > 95: TASKQUEUE_STATS_ONLY(task_queues()->reset_taskqueue_stats()); > 96: Excess newline ------------- Changes requested by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1009 From zgu at openjdk.java.net Tue Jan 5 14:59:10 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 5 Jan 2021 14:59:10 GMT Subject: RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes [v25] In-Reply-To: References: Message-ID: > This is the first part of refactoring, that aims to isolate three Shenandoah GC modes (concurrent, degenerated and full gc). > > Shenandoah started with two GC modes, concurrent and full gc, with minimal shared code, mainly in mark phase. After introducing degenerated GC, it shared quite large portion of code with concurrent GC, with the concept that degenerated GC can simply pick up remaining work of concurrent GC in STW mode. > > It was not a big problem at that time, since concurrent GC also processed roots STW. Since Shenandoah gradually moved root processing into concurrent phase, code started to diverge, that made code hard to reason and maintain. > > First step, I would like to split STW and concurrent mark, so that: > 1) Code has to special case for STW and concurrent mark. > 2) STW mark does not need to rendezvous workers between root mark and the rest of mark > 3) STW mark does not need to activate SATB barrier and drain SATB buffers. > 4) STW mark does not need to remark some of roots. > > The patch mainly just shuffles code. Creates a base class ShenandoahMark, and moved shared code (from current shenandoahConcurrentMark) into this base class. I did 'git mv shenandoahConcurrentMark.inline.hpp shenandoahMark.inline.hpp, but git does not seem to reflect that. > > A few changes: > 1) Moved task queue set from ShenandoahConcurrentMark to ShenandoahHeap. ShenandoahMark and its subclasses are stateless. Instead, mark states are maintained in task queue, mark bitmap and SATB buffers, so that they can be created on demand. > 2) Split ShenandoahConcurrentRootScanner template to ShenandoahConcurrentRootScanner and ShenandoahSTWRootScanner > 3) Split code inside op_final_mark code into finish_mark and prepare_evacuation helper functions. > 4) Made ShenandoahMarkCompact stack allocated (as well as ShenandoahConcurrentGC and ShenandoahDegeneratedGC in upcoming refactoring) Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: @shade's comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1009/files - new: https://git.openjdk.java.net/jdk/pull/1009/files/b7390c08..8cd3f9dc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1009&range=24 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1009&range=23-24 Stats: 51 lines in 7 files changed: 7 ins; 13 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/1009.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1009/head:pull/1009 PR: https://git.openjdk.java.net/jdk/pull/1009 From zgu at openjdk.java.net Tue Jan 5 14:59:12 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 5 Jan 2021 14:59:12 GMT Subject: RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes [v24] In-Reply-To: <4C2MtK5jhW_yHyzDp5k5cAaguy3QlmI0T0LTKf6n978=.8599d416-5d32-40e5-ae7f-9bf5ca5b330d@github.com> References: <4C2MtK5jhW_yHyzDp5k5cAaguy3QlmI0T0LTKf6n978=.8599d416-5d32-40e5-ae7f-9bf5ca5b330d@github.com> Message-ID: On Tue, 5 Jan 2021 14:00:53 GMT, Aleksey Shipilev wrote: >> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: >> >> - Merge >> - Update copyright years >> - Merge >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Concurrent mark does not expect forwarded objects >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Silent valgrind on potential memory leak >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Removed ShenandoahConcurrentMark parameter from concurrent GC entry/op, etc. >> - ... and 21 more: https://git.openjdk.java.net/jdk/compare/a6c08813...b7390c08 > > src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp line 306: > >> 304: ShenandoahHeap* ShenandoahMark::heap() const { >> 305: return _heap; >> 306: } > > Do we really need this method? `ShenandoahHeap::heap()` is supposed to be as fast. No. Quite messy on how to access heap in mark code ... removed _heap member and all access via ShenandoahHeap::heap() ------------- PR: https://git.openjdk.java.net/jdk/pull/1009 From gnu.andrew at redhat.com Tue Jan 5 15:24:16 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 5 Jan 2021 15:24:16 +0000 Subject: [RFR] [8u] 8u282-b02 Upstream Sync In-Reply-To: References: <20201218053435.GA341703@rincewind> Message-ID: <20210105152416.GA420791@rincewind> On 09:50 Mon 04 Jan , Aleksey Shipilev wrote: > On 12/18/20 6:34 AM, Andrew Hughes wrote: > > Merge changesets: > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b02/corba/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b02/jaxp/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b02/jaxws/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b02/jdk/merge.changeset > > Look trivially fine. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b02/hotspot/merge.changeset > > Looks fine. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b02/langtools/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b02/nashorn/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b02/root/merge.changeset > > Look trivially fine. > > > Ok to push? > > Is it still not pushed? Fine to push then. > > -- > Thanks, > -Aleksey > No. Thanks, I'll push it now. -- Andrew :) 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 gnu.andrew at redhat.com Tue Jan 5 15:29:04 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 5 Jan 2021 15:29:04 +0000 Subject: [RFR] [8u] 8u282-b03 Upstream Sync Message-ID: <20210105152904.GB420791@rincewind> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/root/merge.changeset Changes in aarch64-shenandoah-jdk8u282-b03: - JDK-8008657: JSpinner setComponentOrientation doesn't affect on text orientation - JDK-8041592: [TEST_BUG] Move 42 AWT hw/lw mixing tests to jdk - JDK-8163161: [PIT][TEST_BUG] increase timeout in javax/swing/plaf/nimbus/8057791/bug8057791.java - JDK-8168292: [TESTBUG] [macosx] Test java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X - JDK-8168682: jdk/test/java/lang/ClassLoader/forNameLeak/ClassForNameLeak.java fails with -Xcomp - JDK-8223108: Test java/awt/EventQueue/NonComponentSourcePost.java is unstable - JDK-8255603: Memory/Performance regression after JDK-8210985 Main issues of note: None, clean merge (no HotSpot changes). diffstat for root b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for corba b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxp b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxws b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for langtools b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for nashorn b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jdk b/.hgtags | 1 b/src/share/classes/javax/swing/JSpinner.java | 11 b/src/share/classes/javax/swing/plaf/basic/BasicSpinnerUI.java | 35 b/src/share/classes/sun/security/util/Cache.java | 5 b/test/java/awt/EventQueue/NonComponentSourcePost.java | 86 + b/test/java/awt/Mixing/AWT_Mixing/FrameBorderCounter.java | 95 + b/test/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java | 144 + b/test/java/awt/Mixing/AWT_Mixing/HierarchyBoundsListenerMixingTest.java | 692 ++++++++ b/test/java/awt/Mixing/AWT_Mixing/JButtonInGlassPaneOverlapping.java | 51 b/test/java/awt/Mixing/AWT_Mixing/JButtonOverlapping.java | 51 b/test/java/awt/Mixing/AWT_Mixing/JColorChooserOverlapping.java | 54 b/test/java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java | 99 + b/test/java/awt/Mixing/AWT_Mixing/JEditorPaneInGlassPaneOverlapping.java | 53 b/test/java/awt/Mixing/AWT_Mixing/JEditorPaneOverlapping.java | 50 b/test/java/awt/Mixing/AWT_Mixing/JGlassPaneInternalFrameOverlapping.java | 127 + b/test/java/awt/Mixing/AWT_Mixing/JGlassPaneMoveOverlapping.java | 167 ++ b/test/java/awt/Mixing/AWT_Mixing/JInternalFrameMoveOverlapping.java | 124 + b/test/java/awt/Mixing/AWT_Mixing/JInternalFrameOverlapping.java | 102 + b/test/java/awt/Mixing/AWT_Mixing/JLabelInGlassPaneOverlapping.java | 53 b/test/java/awt/Mixing/AWT_Mixing/JLabelOverlapping.java | 52 b/test/java/awt/Mixing/AWT_Mixing/JListInGlassPaneOverlapping.java | 50 b/test/java/awt/Mixing/AWT_Mixing/JListOverlapping.java | 49 b/test/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java | 149 + b/test/java/awt/Mixing/AWT_Mixing/JPanelInGlassPaneOverlapping.java | 53 b/test/java/awt/Mixing/AWT_Mixing/JPanelOverlapping.java | 52 b/test/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java | 124 + b/test/java/awt/Mixing/AWT_Mixing/JProgressBarInGlassPaneOverlapping.java | 53 b/test/java/awt/Mixing/AWT_Mixing/JProgressBarOverlapping.java | 52 b/test/java/awt/Mixing/AWT_Mixing/JScrollBarInGlassPaneOverlapping.java | 67 b/test/java/awt/Mixing/AWT_Mixing/JScrollBarOverlapping.java | 66 b/test/java/awt/Mixing/AWT_Mixing/JScrollPaneOverlapping.java | 129 + b/test/java/awt/Mixing/AWT_Mixing/JSliderInGlassPaneOverlapping.java | 52 b/test/java/awt/Mixing/AWT_Mixing/JSliderOverlapping.java | 51 b/test/java/awt/Mixing/AWT_Mixing/JSpinnerInGlassPaneOverlapping.java | 67 b/test/java/awt/Mixing/AWT_Mixing/JSpinnerOverlapping.java | 64 b/test/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java | 130 + b/test/java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java | 87 + b/test/java/awt/Mixing/AWT_Mixing/JTableOverlapping.java | 73 b/test/java/awt/Mixing/AWT_Mixing/JTextAreaInGlassPaneOverlapping.java | 53 b/test/java/awt/Mixing/AWT_Mixing/JTextAreaOverlapping.java | 52 b/test/java/awt/Mixing/AWT_Mixing/JTextFieldInGlassPaneOverlapping.java | 53 b/test/java/awt/Mixing/AWT_Mixing/JTextFieldOverlapping.java | 52 b/test/java/awt/Mixing/AWT_Mixing/JToggleButtonInGlassPaneOverlapping.java | 51 b/test/java/awt/Mixing/AWT_Mixing/JToggleButtonOverlapping.java | 50 b/test/java/awt/Mixing/AWT_Mixing/MixingFrameResizing.java | 127 + b/test/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java | 462 +++++ b/test/java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java | 164 ++ b/test/java/awt/Mixing/AWT_Mixing/OpaqueOverlappingChoice.java | 48 b/test/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java | 800 ++++++++++ b/test/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java | 160 ++ b/test/java/awt/Mixing/AWT_Mixing/Util.java | 601 +++++++ b/test/java/awt/Mixing/AWT_Mixing/ViewportOverlapping.java | 151 + b/test/java/awt/TrayIcon/DragEventSource/DragEventSource.java | 31 b/test/java/lang/ClassLoader/forNameLeak/ClassForNameLeak.java | 86 - b/test/java/lang/ClassLoader/forNameLeak/test.policy | 1 b/test/javax/swing/JSpinner/8008657/bug8008657.java | 155 + b/test/javax/swing/plaf/nimbus/8057791/bug8057791.java | 7 57 files changed, 6457 insertions(+), 67 deletions(-) diffstat for hotspot b/.hgtags | 1 + 1 file changed, 1 insertion(+) Successfully built on x86, x86_64, s390 (Zero), s390x (Zero), ppc (Zero), ppc64, ppc64le, aarch32 (Zero) & aarch64. Ok to push? Thanks, -- Andrew :) 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 gnu.andrew at redhat.com Tue Jan 5 15:46:52 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 5 Jan 2021 15:46:52 +0000 Subject: [aarch64-port-dev ] RFR: Fix AArch64 build failure after JDK-8062808 backport In-Reply-To: <2683a544-24a2-0046-700f-90eb15d3cbc2@redhat.com> References: <2683a544-24a2-0046-700f-90eb15d3cbc2@redhat.com> Message-ID: <20210105154652.GC420791@rincewind> On 10:27 Mon 04 Jan , Aleksey Shipilev wrote: > My CI catches build failure in current aarch64-port/jdk8u-shenandoah: > > /home/shade/aarch64-port-jdk8u-shenandoah/hotspot/src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp: > In member function ?Address LIR_Assembler::as_Address(LIR_Address*, > Register)?: > /home/shade/aarch64-port-jdk8u-shenandoah/hotspot/src/share/vm/utilities/globalDefinitions_gcc.hpp:223:32: > error: control reaches end of non-void function [-Werror=return-type] > > I believe this only affects 8u aarch64 after -Wreturn-type was enabled (JDK-8062808). > > Note that push to JDK 9 has the "return Address()" in the place we want, but > that addition is missing in aarch64-port/jdk8u-shenandoah! > https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d498aba2c736#l10.210 > > So, a trivial fix is to put in the missing addition: > > diff -r 76dace090781 src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp > --- a/src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp Tue Dec 15 20:18:10 2020 +0100 > +++ b/src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp Mon Jan 04 04:24:42 2021 -0500 > @@ -207,6 +207,7 @@ > return Address(base, tmp, Address::lsl(addr->scale())); > } > } > + return Address(); > } > > I would like to push it to current aarch64-port/jdk8u-shenandoah, which is > stabilizing for 8u282. I believe the patch is innocuous. Andrew, this might > complicate the merges somewhat, please advise whether and when you want this > patch in. > > Testing: 8u aarch64 native build > > -- > Thanks, > -Aleksey > Yes, that would be: https://icedtea.classpath.org//hg/icedtea8-forest/hotspot?cmd=changeset;node=adaf109718c1 https://src.fedoraproject.org/rpms/java-1.8.0-openjdk/blob/master/f/pr3519-fix_further_functions_with_a_missing_return_value.patch which is why my builds didn't catch it. We've been doing -Wreturn-type for a long time, since a case was the cause of a crash with, if I recall correctly, GCC 7. This does mean it is already fixed in the proposed AArch64 merge: https://cr.openjdk.java.net/~andrew/openjdk8/8257192/hotspot/webrev.02/raw_files/new/src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp I'll look at your latest comnents shortly so we can finally get that in for 8u292. If you approve the b03 merge, I can push what I have pending and then this can be committed on top. Thanks for catching it, -- Andrew :) 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 shade at redhat.com Tue Jan 5 16:02:43 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 5 Jan 2021 17:02:43 +0100 Subject: [RFR] [8u] 8u282-b03 Upstream Sync In-Reply-To: <20210105152904.GB420791@rincewind> References: <20210105152904.GB420791@rincewind> Message-ID: <24198778-a4aa-b6fa-0741-3e763ec69f1a@redhat.com> On 1/5/21 4:29 PM, Andrew Hughes wrote: > Merge changesets: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/jaxws/merge.changeset Look trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/jdk/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/hotspot/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/root/merge.changeset Look trivially good. > Ok to push? Yes. -- Thanks, -Aleksey From gnu.andrew at redhat.com Tue Jan 5 16:06:27 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 5 Jan 2021 16:06:27 +0000 Subject: [RFR] [8u] 8u282-b03 Upstream Sync In-Reply-To: <24198778-a4aa-b6fa-0741-3e763ec69f1a@redhat.com> References: <20210105152904.GB420791@rincewind> <24198778-a4aa-b6fa-0741-3e763ec69f1a@redhat.com> Message-ID: <20210105160627.GD420791@rincewind> On 17:02 Tue 05 Jan , Aleksey Shipilev wrote: > On 1/5/21 4:29 PM, Andrew Hughes wrote: > > Merge changesets: > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/corba/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/jaxp/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/jaxws/merge.changeset > > Look trivially good. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/jdk/merge.changeset > > Looks good. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/hotspot/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/langtools/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/nashorn/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b03/root/merge.changeset > > Look trivially good. > > > Ok to push? > > Yes. > > -- > Thanks, > -Aleksey > Thanks, b02 & b03 now pushed. -- Andrew :) 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 zgu at openjdk.java.net Tue Jan 5 18:03:06 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 5 Jan 2021 18:03:06 GMT Subject: RFR: 8259252: Shenandoah: Shenandoah build failed on AArch64 after JDK-8258459 Message-ID: Please review this trivial change that fixes build failure after JDK-8258459 ------------- Commit messages: - Fix build failure Changes: https://git.openjdk.java.net/jdk/pull/1946/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1946&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259252 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1946.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1946/head:pull/1946 PR: https://git.openjdk.java.net/jdk/pull/1946 From rkennke at openjdk.java.net Tue Jan 5 18:21:55 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 5 Jan 2021 18:21:55 GMT Subject: RFR: 8259252: Shenandoah: Shenandoah build failed on AArch64 after JDK-8258459 In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 17:57:47 GMT, Zhengyu Gu wrote: > Please review this trivial change that fixes build failure after JDK-8258459 Looks good! Thanks! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1946 From zgu at openjdk.java.net Tue Jan 5 18:23:13 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 5 Jan 2021 18:23:13 GMT Subject: RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes [v26] In-Reply-To: References: Message-ID: > This is the first part of refactoring, that aims to isolate three Shenandoah GC modes (concurrent, degenerated and full gc). > > Shenandoah started with two GC modes, concurrent and full gc, with minimal shared code, mainly in mark phase. After introducing degenerated GC, it shared quite large portion of code with concurrent GC, with the concept that degenerated GC can simply pick up remaining work of concurrent GC in STW mode. > > It was not a big problem at that time, since concurrent GC also processed roots STW. Since Shenandoah gradually moved root processing into concurrent phase, code started to diverge, that made code hard to reason and maintain. > > First step, I would like to split STW and concurrent mark, so that: > 1) Code has to special case for STW and concurrent mark. > 2) STW mark does not need to rendezvous workers between root mark and the rest of mark > 3) STW mark does not need to activate SATB barrier and drain SATB buffers. > 4) STW mark does not need to remark some of roots. > > The patch mainly just shuffles code. Creates a base class ShenandoahMark, and moved shared code (from current shenandoahConcurrentMark) into this base class. I did 'git mv shenandoahConcurrentMark.inline.hpp shenandoahMark.inline.hpp, but git does not seem to reflect that. > > A few changes: > 1) Moved task queue set from ShenandoahConcurrentMark to ShenandoahHeap. ShenandoahMark and its subclasses are stateless. Instead, mark states are maintained in task queue, mark bitmap and SATB buffers, so that they can be created on demand. > 2) Split ShenandoahConcurrentRootScanner template to ShenandoahConcurrentRootScanner and ShenandoahSTWRootScanner > 3) Split code inside op_final_mark code into finish_mark and prepare_evacuation helper functions. > 4) Made ShenandoahMarkCompact stack allocated (as well as ShenandoahConcurrentGC and ShenandoahDegeneratedGC in upcoming refactoring) Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Silent MacOSX build ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1009/files - new: https://git.openjdk.java.net/jdk/pull/1009/files/8cd3f9dc..dd57c073 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1009&range=25 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1009&range=24-25 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1009.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1009/head:pull/1009 PR: https://git.openjdk.java.net/jdk/pull/1009 From shade at openjdk.java.net Tue Jan 5 18:26:54 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 5 Jan 2021 18:26:54 GMT Subject: RFR: 8259252: Shenandoah: Shenandoah build failed on AArch64 after JDK-8258459 In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 18:22:09 GMT, Aleksey Shipilev wrote: >> Please review this trivial change that fixes build failure after JDK-8258459 > > Looks good. `shenandoahBarrierSetC1_x86.cpp` already has this include. ...and yes, this is trivial. ------------- PR: https://git.openjdk.java.net/jdk/pull/1946 From shade at openjdk.java.net Tue Jan 5 18:26:54 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 5 Jan 2021 18:26:54 GMT Subject: RFR: 8259252: Shenandoah: Shenandoah build failed on AArch64 after JDK-8258459 In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 17:57:47 GMT, Zhengyu Gu wrote: > Please review this trivial change that fixes build failure after JDK-8258459 Looks good. `shenandoahBarrierSetC1_x86.cpp` already has this include. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1946 From shade at redhat.com Tue Jan 5 18:28:48 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 5 Jan 2021 19:28:48 +0100 Subject: [aarch64-port-dev ] RFR: Fix AArch64 build failure after JDK-8062808 backport In-Reply-To: <20210105154652.GC420791@rincewind> References: <2683a544-24a2-0046-700f-90eb15d3cbc2@redhat.com> <20210105154652.GC420791@rincewind> Message-ID: <3e826c95-51e8-1561-1a13-1f3cc38edc3e@redhat.com> On 1/5/21 4:46 PM, Andrew Hughes wrote: > If you approve the b03 merge, I can push what I have pending and then this can be committed on top. Pushed. -- Thanks, -Aleksey From zgu at openjdk.java.net Tue Jan 5 18:37:05 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 5 Jan 2021 18:37:05 GMT Subject: Integrated: 8259252: Shenandoah: Shenandoah build failed on AArch64 after JDK-8258459 In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 17:57:47 GMT, Zhengyu Gu wrote: > Please review this trivial change that fixes build failure after JDK-8258459 This pull request has now been integrated. Changeset: 1b60acd8 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/1b60acd8 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8259252: Shenandoah: Shenandoah build failed on AArch64 after JDK-8258459 Reviewed-by: rkennke, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/1946 From zgu at openjdk.java.net Tue Jan 5 20:36:08 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 5 Jan 2021 20:36:08 GMT Subject: RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes [v27] In-Reply-To: References: Message-ID: > This is the first part of refactoring, that aims to isolate three Shenandoah GC modes (concurrent, degenerated and full gc). > > Shenandoah started with two GC modes, concurrent and full gc, with minimal shared code, mainly in mark phase. After introducing degenerated GC, it shared quite large portion of code with concurrent GC, with the concept that degenerated GC can simply pick up remaining work of concurrent GC in STW mode. > > It was not a big problem at that time, since concurrent GC also processed roots STW. Since Shenandoah gradually moved root processing into concurrent phase, code started to diverge, that made code hard to reason and maintain. > > First step, I would like to split STW and concurrent mark, so that: > 1) Code has to special case for STW and concurrent mark. > 2) STW mark does not need to rendezvous workers between root mark and the rest of mark > 3) STW mark does not need to activate SATB barrier and drain SATB buffers. > 4) STW mark does not need to remark some of roots. > > The patch mainly just shuffles code. Creates a base class ShenandoahMark, and moved shared code (from current shenandoahConcurrentMark) into this base class. I did 'git mv shenandoahConcurrentMark.inline.hpp shenandoahMark.inline.hpp, but git does not seem to reflect that. > > A few changes: > 1) Moved task queue set from ShenandoahConcurrentMark to ShenandoahHeap. ShenandoahMark and its subclasses are stateless. Instead, mark states are maintained in task queue, mark bitmap and SATB buffers, so that they can be created on demand. > 2) Split ShenandoahConcurrentRootScanner template to ShenandoahConcurrentRootScanner and ShenandoahSTWRootScanner > 3) Split code inside op_final_mark code into finish_mark and prepare_evacuation helper functions. > 4) Made ShenandoahMarkCompact stack allocated (as well as ShenandoahConcurrentGC and ShenandoahDegeneratedGC in upcoming refactoring) Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: - Merge branch 'master' into JDK-8255019-sh-mark - Silent MacOSX build - @shade's comments - Merge - Update copyright years - Merge - Merge branch 'master' into JDK-8255019-sh-mark - Concurrent mark does not expect forwarded objects - Merge branch 'master' into JDK-8255019-sh-mark - Merge branch 'master' into JDK-8255019-sh-mark - ... and 24 more: https://git.openjdk.java.net/jdk/compare/4d3d5991...a6540b99 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1009/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1009&range=26 Stats: 1978 lines in 21 files changed: 1078 ins; 759 del; 141 mod Patch: https://git.openjdk.java.net/jdk/pull/1009.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1009/head:pull/1009 PR: https://git.openjdk.java.net/jdk/pull/1009 From shade at redhat.com Wed Jan 6 11:50:47 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 Jan 2021 12:50:47 +0100 Subject: SoftMaxHeapSize has no effect with Cassandra In-Reply-To: References: Message-ID: Hi, On 12/14/20 12:15 AM, Kornel Pal wrote: > Thank you for implementing SoftMaxHeapSize, it greatly simplifies > keeping the heap utilization low while also providing a buffer for > allocation spikes. > > I've tried it with Cassandra using the latest > openjdk-shenandoah-jdk8-linux-x86_64-server-release.tar.xz nightly build > and the default adaptive heuristics, but unfortunately > ShenandoahSoftMaxHeapSize does not seem to have any effect on the GC. > Setting ShenandoahMinFreeThreshold=50 on the other hand resulted in a > behavior similar to what I would expect from setting > ShenandoahSoftMaxHeapSize to half the size of the heap. Please post the full list of GC flags you are using? And maybe the excerpts from the GC logs that show unexpected (with ShenandoahSoftMaxHeapSize setting) and expected (with ShenandoahMinFreeThreshold setting) behaviors? This is only to confirm that we are seeing the same issue. > Cassandra is allocating short-lived objects at a high rate, that might > be a different allocation pattern than what SoftMaxHeapSize was tested with. > > I am not very familiar with the Shenandoah code, but I think that while > should_start_gc() removes soft tail from the available heap, > choose_collection_set_from_regiondata() is not removing soft tail from > actual_free (or increasing free_target with the soft tail), that results > in no GC being performed, even when heap utilization is above the soft > limit. > > Could you please check whether ShenandoahSoftMaxHeapSize in sh/8u is > behaving as expected. I think you are right here. This bug manifests when heap is fragmented enough: the GC cycle triggers, but finds no candidate regions to compact the heap to the new soft max target. Filed: https://bugs.openjdk.java.net/browse/JDK-8259310 -- Thanks, -Aleksey From gnu.andrew at redhat.com Wed Jan 6 20:04:01 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 6 Jan 2021 20:04:01 +0000 Subject: [RFR] [8u] 8u282-b04 Upstream Sync Message-ID: <20210106200401.GA578088@rincewind> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b04/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b04/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b04/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b04/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b04/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b04/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b04/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b04/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b04/root/merge.changeset Changes in aarch64-shenandoah-jdk8u282-b04: - Fix AArch64 build failure after JDK-8062808 backport (already upstream) - JDK-8022535: [TEST BUG] javax/swing/text/html/parser/Test8017492.java fails - JDK-8043126: move awt automated functional tests from AWT_Events/Lw and AWT_Events/AWT to OpenJDK repository - JDK-8043131: Move ShapedAndTranslucentWindows and GC functional AWT tests to regression tree - JDK-8043899: compiler/5091921/Test7005594.java fails if specified -Xmx is less than 1600m - JDK-8044157: [TEST_BUG] Improve recently submitted AWT_Mixing tests - JDK-8044172: [TEST_BUG] Move regtests for 4523758 and AltPlusNumberKeyCombinationsTest to jdk - JDK-8044429: move awt automated tests for AWT_Modality to OpenJDK repository - JDK-8044765: Move functional tests AWT_SystemTray/Automated to openjdk repository - JDK-8046221: [TEST_BUG] Cleanup datatransfer tests - JDK-8047180: Move functional tests AWT_Headless/Automated to OpenJDK repository - JDK-8047367: move awt automated tests from AWT_Modality to OpenJDK repository - part 2 - JDK-8048246: Move AWT_DnD/Clipboard/Automated functional tests to OpenJDK - JDK-8049617: move awt automated tests from AWT_Modality to OpenJDK repository - part 3 - JDK-8049694: Migrate functional AWT_DesktopProperties/Automated tests to OpenJDK - JDK-8050885: move awt automated tests from AWT_Modality to OpenJDK repository - part 4 - JDK-8051440: move tests about maximizing undecorated to OpenJDK - JDK-8052012: move awt automated tests from AWT_Modality to OpenJDK repository - part 5 - JDK-8052408: Move AWT_BAT functional tests to OpenJDK (3 of 3) - JDK-8053657: [TEST_BUG] move some 5 tests related to undecorated Frame/JFrame to JDK - JDK-8054143: move awt automated tests from AWT_Modality to OpenJDK repository - part 6 - JDK-8054358: move awt automated tests from AWT_Modality to OpenJDK repository - part 7 - JDK-8054359: move awt automated tests from AWT_Modality to OpenJDK repository - part 8 - JDK-8055360: Move the rest part of AWT ShapedAndTranslucent tests to OpenJDK - JDK-8055664: move 14 tests about setLocationRelativeTo to jdk - JDK-8055836: move awt tests from AWT_Modality to OpenJDK repository - part 9 - JDK-8057694: move awt tests from AWT_Modality to OpenJDK repository - part 10 - JDK-8058805: [TEST_BUG]Test java/awt/TrayIcon/SecurityCheck/NoPermissionTest/NoPermissionTest.java fails - JDK-8063102: Change open awt regression tests to avoid sun.awt.SunToolkit.realSync, part 1 - JDK-8063104: Change open awt regression tests to avoid sun.awt.SunToolkit.realSync, part 2 - JDK-8063106: Change open swing regression tests to avoid sun.awt.SunToolkit.realSync, part 1 - JDK-8063107: Change open swing regression tests to avoid sun.awt.SunToolkit.realSync, part 2 - JDK-8064573: [TEST_BUG] javax/swing/text/AbstractDocument/6968363/Test6968363.java is asocial pressing VK_LEFT and not releasing - JDK-8064575: [TEST_BUG] javax/swing/JEditorPane/6917744/bug6917744.java 100 times press keys and never releases - JDK-8064809: [TEST_BUG] javax/swing/JComboBox/4199622/bug4199622.java contains a lot of keyPress and not a single keyRelease - JDK-8067441: Some tests fails with error: cannot find symbol getSystemMnemonicKeyCodes() - JDK-8068228: Test closed/java/awt/Mouse/MaximizedFrameTest/MaximizedFrameTest fails with GTKLookAndFeel - JDK-8068275: Some tests failed after JDK-8063104 - JDK-8069211: (zipfs) ZipFileSystem creates corrupted zip if entry output stream gets closed more than once - JDK-8074807: Fix some tests unnecessary using internal API - JDK-8076315: move 4 manual functional swing tests to regression suite - JDK-8130772: Util.hitMnemonics does not work: getSystemMnemonicKeyCodes() returns ALT_MASK rather than VK_ALT - JDK-8152545: Use preprocessor instead of compiling a program to generate native nio constants - JDK-8156803: Turn StressLCM/StressGCM flags to diagnostic - JDK-8160761: [TESTBUG] Several compiler tests fail with product bits - JDK-8166015: [PIT][TEST_BUG] stray character in java/awt/Focus/ModalDialogActivationTest/ModalDialogActivationTest.java - JDK-8166583: Add oopDesc::klass_or_null_acquire() - JDK-8166663: Simplify oops_on_card_seq_iterate_careful - JDK-8166862: CMS needs klass_or_null_acquire - JDK-8179083: Uninitialized notifier in Java Monitor Wait tracing event - JDK-8205507: jdk/javax/xml/crypto/dsig/GenerationTests.java timed out - JDK-8217362: Emergency dump does not work when disk=false is set - JDK-8217766: Container Support doesn't work for some Join Controllers combinations - JDK-8219013: Update Apache Santuario (XML Signature) to version 2.1.3 - JDK-8219562: Line of code in osContainer_linux.cpp L102 appears unreachable - JDK-8220579: [Containers] SubSystem.java out of sync with osContainer_linux.cpp - JDK-8221340: [TESTBUG] TestCgroupMetrics.java fails after fix for JDK-8219562 - JDK-8221710: [TESTBUG] more configurable parameters for docker testing - JDK-8227006: [linux] Runtime.availableProcessors execution time increased by factor of 100 - JDK-8229868: Update Apache Santuario TPRM version - JDK-8233548: Update CUP to v0.11b - JDK-8242480: Negative value may be returned by getFreeSwapSpaceSize() in the docker - JDK-8246648: issue with OperatingSystemImpl getFreeSwapSpaceSize in docker after 8242480 - JDK-8249846: Change of behavior after JDK-8237117: Better ForkJoinPool behavior - JDK-8250636: iso8601_time returns incorrect offset part on MacOS - JDK-8251365: Build failure on AIX after 8250636 - JDK-8255717: Fix JFR crash in WriteObjectSampleStacktrace due to object not initialized - JDK-8256618: Zero: Linux x86_32 build still fails - JDK-8256671: Incorrect assignment operator used in guarantee() in genCollectedHeap - JDK-8256752: 8252395 incorrect copy rule for macos .dSYM folder - JDK-8257397: [TESTBUG] test/lib/containers/docker/Common.java refers to -Xlog:os+container=trace Main issues of note: aarch64/shenandoah-jdk8u had a local change in make/gensrc/GensrcMisc.gmk, with LDEXE := $(BUILD_LD) changed to LDEXE := $(BUILD_CC). This entire block was removed by JDK-8152545, a change designed to address the problem which this local change worked around. Now the sources are only pre-processed, there is no linking stage to cause an issue. diffstat for root b/.hgtags | 1 + b/THIRD_PARTY_README | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) diffstat for corba b/.hgtags | 1 + b/THIRD_PARTY_README | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) diffstat for jaxp b/.hgtags | 1 b/THIRD_PARTY_README | 6 b/src/com/sun/org/apache/xalan/internal/xsltc/compiler/XPathParser.java | 4830 ++++------ 3 files changed, 2236 insertions(+), 2601 deletions(-) diffstat for jaxws b/.hgtags | 1 + b/THIRD_PARTY_README | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) diffstat for langtools b/.hgtags | 1 + b/THIRD_PARTY_README | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) diffstat for nashorn b/.hgtags | 1 + b/THIRD_PARTY_README | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) diffstat for jdk a/make/src/native/genconstants/ch/genSocketOptionRegistry.c | 131 - a/make/src/native/genconstants/fs/genSolarisConstants.c | 105 - a/make/src/native/genconstants/fs/genUnixConstants.c | 141 - a/test/java/awt/DataFlavor/MissedHtmlAndRtfBug/AbsoluteComponentCenterCalculator.java | 37 a/test/java/awt/DataFlavor/MissedHtmlAndRtfBug/DataFlavorSearcher.java | 47 a/test/java/awt/DataFlavor/MissedHtmlAndRtfBug/InterprocessMessages.java | 29 a/test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.html | 48 a/test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.java | 199 -- a/test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MyTransferable.java | 62 a/test/java/awt/DataFlavor/MissedHtmlAndRtfBug/NextFramePositionCalculator.java | 43 a/test/java/awt/DataFlavor/MissedHtmlAndRtfBug/SourcePanel.java | 49 a/test/java/awt/DataFlavor/MissedHtmlAndRtfBug/TargetPanel.java | 106 - a/test/java/awt/Mixing/AWT_Mixing/Util.java | 601 ------- a/test/java/awt/Mouse/MaximizedFrameTest/MaximizedFrameTest.html | 42 a/test/java/awt/datatransfer/DuplicatedNativesTest/DuplicatedNativesTest.java | 57 a/test/java/awt/datatransfer/MappingGenerationTest/MappingGenerationTest.java | 183 -- b/.hgtags | 1 b/THIRD_PARTY_README | 8 b/make/CompileLaunchers.gmk | 2 b/make/gensrc/GensrcMisc.gmk | 135 - b/src/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java | 15 b/src/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java | 6 b/src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java | 14 b/src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureDSA.java | 4 b/src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureECDSA.java | 4 b/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315.java | 2 b/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315Excl.java | 2 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/KeyInfo.java | 1 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyValue.java | 8 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/keyvalues/ECKeyValue.java | 366 ++++ b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509SKI.java | 6 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolver.java | 2 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/ECKeyValueResolver.java | 97 + b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/RSAKeyValueResolver.java | 3 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/CertsInFilesystemDirectoryResolver.java | 4 b/src/share/classes/com/sun/org/apache/xml/internal/security/resource/config.xml | 4 b/src/share/classes/com/sun/org/apache/xml/internal/security/signature/Manifest.java | 58 b/src/share/classes/com/sun/org/apache/xml/internal/security/signature/Reference.java | 20 b/src/share/classes/com/sun/org/apache/xml/internal/security/signature/VerifiedReference.java | 64 b/src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignature.java | 7 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformBase64Decode.java | 13 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXSLT.java | 5 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPathFilterCHGPContainer.java | 17 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/Constants.java | 3 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementProxy.java | 29 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/Signature11ElementProxy.java | 7 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/XMLUtils.java | 15 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolver.java | 2 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverDirectHTTP.java | 8 b/src/share/classes/java/util/concurrent/ForkJoinPool.java | 14 b/src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheOctetStreamData.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14NMethod.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCryptoBinary.java | 24 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMDigestMethod.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMEnvelopedTransform.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMExcC14NMethod.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMHMACSignatureMethod.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfo.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfoFactory.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyName.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java | 18 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java | 14 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java | 9 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureMethod.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperty.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMStructure.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMTransform.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMUtils.java | 6 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509Data.java | 16 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509IssuerSerial.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLObject.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java | 7 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignatureFactory.java | 6 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathTransform.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXSLTTransform.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java | 4 b/src/share/classes/sun/nio/ch/SocketOptionRegistry.java.template | 137 + b/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java | 14 b/src/solaris/classes/sun/management/OperatingSystemImpl.java | 14 b/src/solaris/classes/sun/nio/fs/SolarisConstants.java.template | 89 + b/src/unix/classes/sun/nio/fs/UnixConstants.java.template | 132 + b/test/com/sun/awt/Translucency/WindowOpacity.java | 15 b/test/com/sun/java/swing/plaf/windows/8016551/bug8016551.java | 7 b/test/demo/zipfs/ZipFSTester.java | 26 b/test/demo/zipfs/basic.sh | 2 b/test/java/awt/AlphaComposite/HeadlessAlphaComposite.java | 63 b/test/java/awt/Choice/DragMouseOutAndRelease/DragMouseOutAndRelease.java | 421 +++++ b/test/java/awt/Choice/GetSizeTest/GetSizeTest.java | 104 + b/test/java/awt/Choice/GrabLockTest/GrabLockTest.java | 110 + b/test/java/awt/Choice/PopupPosTest/PopupPosTest.html | 46 b/test/java/awt/Choice/PopupPosTest/PopupPosTest.java | 150 + b/test/java/awt/Choice/ResizeAutoClosesChoice/ResizeAutoClosesChoice.java | 113 + b/test/java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.html | 44 b/test/java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.java | 323 ++++ b/test/java/awt/Choice/UnfocusableCB_ERR/UnfocusableCB_ERR.java | 421 +++++ b/test/java/awt/Color/HeadlessColor.java | 225 ++ b/test/java/awt/Component/7097771/bug7097771.java | 15 b/test/java/awt/Component/CompEventOnHiddenComponent/CompEventOnHiddenComponent.java | 441 +++++ b/test/java/awt/Component/F10TopToplevel/F10TopToplevel.java | 15 b/test/java/awt/Component/Headless/HeadlessButton.java | 57 b/test/java/awt/Component/Headless/HeadlessCanvas.java | 37 b/test/java/awt/Component/Headless/HeadlessCheckbox.java | 110 + b/test/java/awt/Component/Headless/HeadlessChoice.java | 44 b/test/java/awt/Component/Headless/HeadlessComponent.java | 199 ++ b/test/java/awt/Component/Headless/HeadlessContainer.java | 216 ++ b/test/java/awt/Component/Headless/HeadlessDialog.java | 92 + b/test/java/awt/Component/Headless/HeadlessFileDialog.java | 72 b/test/java/awt/Component/Headless/HeadlessFrame.java | 55 b/test/java/awt/Component/Headless/HeadlessLabel.java | 64 b/test/java/awt/Component/Headless/HeadlessList.java | 100 + b/test/java/awt/Component/Headless/HeadlessPanel.java | 218 ++ b/test/java/awt/Component/Headless/HeadlessScrollPane.java | 72 b/test/java/awt/Component/Headless/HeadlessScrollbar.java | 82 + b/test/java/awt/Component/Headless/HeadlessTextArea.java | 108 + b/test/java/awt/Component/Headless/HeadlessTextField.java | 88 + b/test/java/awt/Component/Headless/HeadlessWindow.java | 43 b/test/java/awt/Component/NativeInLightShow/NativeInLightShow.java | 92 + b/test/java/awt/Component/NoUpdateUponShow/NoUpdateUponShow.java | 9 b/test/java/awt/Component/PaintAll/PaintAll.java | 17 b/test/java/awt/Cursor/HeadlessCursor.java | 93 + b/test/java/awt/EventQueue/HeadlessEventQueue.java | 37 b/test/java/awt/FileDialog/ISCthrownByFileListTest/ISCthrownByFileListTest.java | 121 + b/test/java/awt/Focus/6378278/InputVerifierTest.java | 413 +++++ b/test/java/awt/Focus/6382144/EndlessLoopTest.java | 409 +++++ b/test/java/awt/Focus/6401036/InputVerifierTest2.java | 384 ++++ b/test/java/awt/Focus/ChildWindowFocusTest/ChildWindowFocusTest.html | 43 b/test/java/awt/Focus/ChildWindowFocusTest/ChildWindowFocusTest.java | 281 +++ b/test/java/awt/Focus/DisposedWindow/DisposeDialogNotActivateOwnerTest/DisposeDialogNotActivateOwnerTest.html | 43 b/test/java/awt/Focus/DisposedWindow/DisposeDialogNotActivateOwnerTest/DisposeDialogNotActivateOwnerTest.java | 258 +++ b/test/java/awt/Focus/FocusEmbeddedFrameTest/FocusEmbeddedFrameTest.java | 5 b/test/java/awt/Focus/FocusSubRequestTest/FocusSubRequestTest.html | 43 b/test/java/awt/Focus/FocusSubRequestTest/FocusSubRequestTest.java | 98 + b/test/java/awt/Focus/Headless/HeadlessContainerOrderFocusTraversalPolicy.java | 66 b/test/java/awt/Focus/Headless/HeadlessDefaultFocusTraversalPolicy.java | 67 b/test/java/awt/Focus/Headless/HeadlessDefaultKeyboardFocusManager.java | 37 b/test/java/awt/Focus/KeyEventForBadFocusOwnerTest/KeyEventForBadFocusOwnerTest.java | 8 b/test/java/awt/Focus/ModalBlockedStealsFocusTest/ModalBlockedStealsFocusTest.java | 10 b/test/java/awt/Focus/ModalDialogActivationTest/ModalDialogActivationTest.java | 21 b/test/java/awt/Focus/ModalDialogInitialFocusTest/ModalDialogInitialFocusTest.html | 43 b/test/java/awt/Focus/ModalDialogInitialFocusTest/ModalDialogInitialFocusTest.java | 253 +++ b/test/java/awt/Focus/ModalExcludedWindowClickTest/ModalExcludedWindowClickTest.html | 43 b/test/java/awt/Focus/ModalExcludedWindowClickTest/ModalExcludedWindowClickTest.java | 291 +++ b/test/java/awt/Focus/MouseClickRequestFocusRaceTest/MouseClickRequestFocusRaceTest.html | 43 b/test/java/awt/Focus/MouseClickRequestFocusRaceTest/MouseClickRequestFocusRaceTest.java | 307 +++ b/test/java/awt/Focus/NonFocusableBlockedOwnerTest/NonFocusableBlockedOwnerTest.html | 43 b/test/java/awt/Focus/NonFocusableBlockedOwnerTest/NonFocusableBlockedOwnerTest.java | 288 +++ b/test/java/awt/Focus/SimpleWindowActivationTest/SimpleWindowActivationTest.java | 12 b/test/java/awt/Focus/WindowInitialFocusTest/WindowInitialFocusTest.java | 17 b/test/java/awt/Focus/WindowUpdateFocusabilityTest/WindowUpdateFocusabilityTest.html | 43 b/test/java/awt/Focus/WindowUpdateFocusabilityTest/WindowUpdateFocusabilityTest.java | 325 ++++ b/test/java/awt/FontClass/HeadlessFont.java | 239 +++ b/test/java/awt/Frame/DisposeParentGC/DisposeParentGC.java | 166 ++ b/test/java/awt/Frame/ExceptionOnSetExtendedStateTest/ExceptionOnSetExtendedStateTest.java | 11 b/test/java/awt/Frame/FrameSize/TestFrameSize.java | 8 b/test/java/awt/Frame/FramesGC/FramesGC.java | 159 ++ b/test/java/awt/Frame/GetBoundsResizeTest/GetBoundsResizeTest.java | 168 ++ b/test/java/awt/Frame/MaximizedByPlatform/MaximizedByPlatform.java | 18 b/test/java/awt/Frame/MaximizedToMaximized/MaximizedToMaximized.java | 5 b/test/java/awt/Frame/MaximizedUndecorated/MaximizedUndecorated.java | 100 + b/test/java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java | 215 ++ b/test/java/awt/Frame/MiscUndecorated/ActiveSwingWindowTest.java | 219 ++ b/test/java/awt/Frame/MiscUndecorated/FrameCloseTest.java | 212 ++ b/test/java/awt/Frame/MiscUndecorated/RepaintTest.java | 302 +++ b/test/java/awt/Frame/MiscUndecorated/UndecoratedInitiallyIconified.java | 56 b/test/java/awt/Frame/SlideNotResizableTest/SlideNotResizableTest.java | 7 b/test/java/awt/FullScreen/8013581/bug8013581.java | 14 b/test/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java | 14 b/test/java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java | 15 b/test/java/awt/GradientPaint/HeadlessGradientPaint.java | 51 b/test/java/awt/Graphics2D/Headless/HeadlessPoint.java | 44 b/test/java/awt/Graphics2D/Headless/HeadlessPolygon.java | 37 b/test/java/awt/Graphics2D/Headless/HeadlessRectangle.java | 70 b/test/java/awt/GraphicsConfiguration/HeadlessGraphicsConfiguration.java | 53 b/test/java/awt/GraphicsDevice/HeadlessGraphicsDevice.java | 50 b/test/java/awt/GraphicsDevice/IncorrectDisplayModeExitFullscreen.java | 20 b/test/java/awt/GraphicsEnvironment/HeadlessGraphicsEnvironment.java | 76 b/test/java/awt/GridBagLayout/GridBagLayoutIpadXYTest/GridBagLayoutIpadXYTest.java | 9 b/test/java/awt/Headless/HeadlessAWTEventMulticaster.java | 247 +++ b/test/java/awt/Headless/HeadlessAWTException.java | 37 b/test/java/awt/Headless/HeadlessBasicStroke.java | 151 + b/test/java/awt/Headless/HeadlessBorderLayout.java | 62 b/test/java/awt/Headless/HeadlessCardLayout.java | 44 b/test/java/awt/Headless/HeadlessCheckboxGroup.java | 38 b/test/java/awt/Headless/HeadlessCheckboxMenuItem.java | 75 b/test/java/awt/Headless/HeadlessComponentOrientation.java | 46 b/test/java/awt/Headless/HeadlessDimension.java | 59 b/test/java/awt/Headless/HeadlessFlowLayout.java | 42 b/test/java/awt/Headless/HeadlessMediaTracker.java | 37 b/test/java/awt/Headless/HeadlessPopupMenu.java | 53 b/test/java/awt/Insets/HeadlessInsets.java | 37 b/test/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeForModalDialogTest/ConsumeForModalDialogTest.html | 43 b/test/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeForModalDialogTest/ConsumeForModalDialogTest.java | 281 +++ b/test/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest.html | 45 b/test/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest.java | 300 +++ b/test/java/awt/KeyboardFocusmanager/TypeAhead/EnqueueWithDialogButtonTest/EnqueueWithDialogButtonTest.java | 374 ++++ b/test/java/awt/KeyboardFocusmanager/TypeAhead/EnqueueWithDialogTest/EnqueueWithDialogTest.java | 239 +++ b/test/java/awt/KeyboardFocusmanager/TypeAhead/FreezeTest/FreezeTest.java | 219 ++ b/test/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.java | 5 b/test/java/awt/List/ActionAfterRemove/ActionAfterRemove.java | 24 b/test/java/awt/List/EmptyListEventTest/EmptyListEventTest.java | 14 b/test/java/awt/List/KeyEventsTest/KeyEventsTest.html | 46 b/test/java/awt/List/KeyEventsTest/KeyEventsTest.java | 370 ++++ b/test/java/awt/List/ListPeer/R2303044ListSelection.java | 10 b/test/java/awt/List/NofocusListDblClickTest/NofocusListDblClickTest.java | 10 b/test/java/awt/List/ScrollOutside/ScrollOut.java | 9 b/test/java/awt/List/SetBackgroundTest/SetBackgroundTest.java | 357 ---- b/test/java/awt/List/SingleModeDeselect/SingleModeDeselect.java | 9 b/test/java/awt/Menu/Headless/HeadlessMenu.java | 72 b/test/java/awt/Menu/Headless/HeadlessMenuItem.java | 67 b/test/java/awt/Menu/Headless/HeadlessMenuShortcut.java | 41 b/test/java/awt/MenuBar/8007006/bug8007006.java | 28 b/test/java/awt/MenuBar/HeadlessMenuBar.java | 44 b/test/java/awt/MenuBar/MenuBarSetFont/MenuBarSetFont.java | 27 b/test/java/awt/Mixing/AWT_Mixing/FrameBorderCounter.java | 5 b/test/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java | 1 b/test/java/awt/Mixing/AWT_Mixing/HierarchyBoundsListenerMixingTest.java | 9 b/test/java/awt/Mixing/AWT_Mixing/JButtonInGlassPaneOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JButtonOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JColorChooserOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java | 4 b/test/java/awt/Mixing/AWT_Mixing/JEditorPaneInGlassPaneOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JEditorPaneOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JGlassPaneInternalFrameOverlapping.java | 5 b/test/java/awt/Mixing/AWT_Mixing/JGlassPaneMoveOverlapping.java | 5 b/test/java/awt/Mixing/AWT_Mixing/JInternalFrameMoveOverlapping.java | 3 b/test/java/awt/Mixing/AWT_Mixing/JInternalFrameOverlapping.java | 3 b/test/java/awt/Mixing/AWT_Mixing/JLabelInGlassPaneOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JLabelOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JListInGlassPaneOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JListOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java | 5 b/test/java/awt/Mixing/AWT_Mixing/JPanelInGlassPaneOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JPanelOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java | 3 b/test/java/awt/Mixing/AWT_Mixing/JProgressBarInGlassPaneOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JProgressBarOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JScrollBarInGlassPaneOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JScrollBarOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JScrollPaneOverlapping.java | 3 b/test/java/awt/Mixing/AWT_Mixing/JSliderInGlassPaneOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JSliderOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JSpinnerInGlassPaneOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JSpinnerOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java | 5 b/test/java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JTableOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JTextAreaInGlassPaneOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JTextAreaOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JTextFieldInGlassPaneOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JTextFieldOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JToggleButtonInGlassPaneOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/JToggleButtonOverlapping.java | 2 b/test/java/awt/Mixing/AWT_Mixing/MixingFrameResizing.java | 5 b/test/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java | 9 b/test/java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java | 3 b/test/java/awt/Mixing/AWT_Mixing/OpaqueOverlappingChoice.java | 2 b/test/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java | 22 b/test/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java | 5 b/test/java/awt/Mixing/AWT_Mixing/ViewportOverlapping.java | 5 b/test/java/awt/Modal/FileDialog/FileDialogAppModal1Test.java | 49 b/test/java/awt/Modal/FileDialog/FileDialogAppModal2Test.java | 49 b/test/java/awt/Modal/FileDialog/FileDialogAppModal3Test.java | 49 b/test/java/awt/Modal/FileDialog/FileDialogAppModal4Test.java | 49 b/test/java/awt/Modal/FileDialog/FileDialogAppModal5Test.java | 49 b/test/java/awt/Modal/FileDialog/FileDialogAppModal6Test.java | 48 b/test/java/awt/Modal/FileDialog/FileDialogDWDTest.java | 233 ++ b/test/java/awt/Modal/FileDialog/FileDialogDocModal1Test.java | 49 b/test/java/awt/Modal/FileDialog/FileDialogDocModal2Test.java | 49 b/test/java/awt/Modal/FileDialog/FileDialogDocModal3Test.java | 49 b/test/java/awt/Modal/FileDialog/FileDialogDocModal4Test.java | 49 b/test/java/awt/Modal/FileDialog/FileDialogDocModal5Test.java | 49 b/test/java/awt/Modal/FileDialog/FileDialogDocModal6Test.java | 48 b/test/java/awt/Modal/FileDialog/FileDialogDocModal7Test.java | 45 b/test/java/awt/Modal/FileDialog/FileDialogFWDTest.java | 291 +++ b/test/java/awt/Modal/FileDialog/FileDialogModal1Test.java | 48 b/test/java/awt/Modal/FileDialog/FileDialogModal2Test.java | 48 b/test/java/awt/Modal/FileDialog/FileDialogModal3Test.java | 48 b/test/java/awt/Modal/FileDialog/FileDialogModal4Test.java | 48 b/test/java/awt/Modal/FileDialog/FileDialogModal5Test.java | 48 b/test/java/awt/Modal/FileDialog/FileDialogModal6Test.java | 47 b/test/java/awt/Modal/FileDialog/FileDialogModalityTest.java | 180 ++ b/test/java/awt/Modal/FileDialog/FileDialogNonModal1Test.java | 48 b/test/java/awt/Modal/FileDialog/FileDialogNonModal2Test.java | 48 b/test/java/awt/Modal/FileDialog/FileDialogNonModal3Test.java | 48 b/test/java/awt/Modal/FileDialog/FileDialogNonModal4Test.java | 48 b/test/java/awt/Modal/FileDialog/FileDialogNonModal5Test.java | 48 b/test/java/awt/Modal/FileDialog/FileDialogNonModal6Test.java | 47 b/test/java/awt/Modal/FileDialog/FileDialogNonModal7Test.java | 45 b/test/java/awt/Modal/FileDialog/FileDialogTKModal1Test.java | 49 b/test/java/awt/Modal/FileDialog/FileDialogTKModal2Test.java | 49 b/test/java/awt/Modal/FileDialog/FileDialogTKModal3Test.java | 49 b/test/java/awt/Modal/FileDialog/FileDialogTKModal4Test.java | 49 b/test/java/awt/Modal/FileDialog/FileDialogTKModal5Test.java | 49 b/test/java/awt/Modal/FileDialog/FileDialogTKModal6Test.java | 48 b/test/java/awt/Modal/FileDialog/FileDialogTKModal7Test.java | 45 b/test/java/awt/Modal/ModalBlockingTests/BlockingDDAppModalTest.java | 46 b/test/java/awt/Modal/ModalBlockingTests/BlockingDDDocModalTest.java | 46 b/test/java/awt/Modal/ModalBlockingTests/BlockingDDModelessTest.java | 46 b/test/java/awt/Modal/ModalBlockingTests/BlockingDDNonModalTest.java | 44 b/test/java/awt/Modal/ModalBlockingTests/BlockingDDSetModalTest.java | 45 b/test/java/awt/Modal/ModalBlockingTests/BlockingDDTest.java | 124 + b/test/java/awt/Modal/ModalBlockingTests/BlockingDDToolkitModalTest.java | 46 b/test/java/awt/Modal/ModalBlockingTests/BlockingDFAppModalTest.java | 46 b/test/java/awt/Modal/ModalBlockingTests/BlockingDFSetModalTest.java | 46 b/test/java/awt/Modal/ModalBlockingTests/BlockingDFTest.java | 97 + b/test/java/awt/Modal/ModalBlockingTests/BlockingDFToolkitModalTest.java | 46 b/test/java/awt/Modal/ModalBlockingTests/BlockingDFWModeless1Test.java | 50 b/test/java/awt/Modal/ModalBlockingTests/BlockingDFWModeless2Test.java | 50 b/test/java/awt/Modal/ModalBlockingTests/BlockingDFWNonModal1Test.java | 48 b/test/java/awt/Modal/ModalBlockingTests/BlockingDFWNonModal2Test.java | 48 b/test/java/awt/Modal/ModalBlockingTests/BlockingDFWTest.java | 162 ++ b/test/java/awt/Modal/ModalBlockingTests/BlockingDocModalTest.java | 153 + b/test/java/awt/Modal/ModalBlockingTests/BlockingFDAppModalTest.java | 47 b/test/java/awt/Modal/ModalBlockingTests/BlockingFDDocModalTest.java | 47 b/test/java/awt/Modal/ModalBlockingTests/BlockingFDModelessTest.java | 47 b/test/java/awt/Modal/ModalBlockingTests/BlockingFDNonModalTest.java | 46 b/test/java/awt/Modal/ModalBlockingTests/BlockingFDSetModalTest.java | 46 b/test/java/awt/Modal/ModalBlockingTests/BlockingFDTest.java | 124 + b/test/java/awt/Modal/ModalBlockingTests/BlockingFDToolkitModalTest.java | 47 b/test/java/awt/Modal/ModalBlockingTests/BlockingFDWDocModal1Test.java | 49 b/test/java/awt/Modal/ModalBlockingTests/BlockingFDWDocModal2Test.java | 49 b/test/java/awt/Modal/ModalBlockingTests/BlockingFDWDocModal3Test.java | 49 b/test/java/awt/Modal/ModalBlockingTests/BlockingFDWDocModal4Test.java | 49 b/test/java/awt/Modal/ModalBlockingTests/BlockingFDWModeless1Test.java | 49 b/test/java/awt/Modal/ModalBlockingTests/BlockingFDWModeless2Test.java | 49 b/test/java/awt/Modal/ModalBlockingTests/BlockingFDWModeless3Test.java | 49 b/test/java/awt/Modal/ModalBlockingTests/BlockingFDWModeless4Test.java | 49 b/test/java/awt/Modal/ModalBlockingTests/BlockingFDWNonModal1Test.java | 47 b/test/java/awt/Modal/ModalBlockingTests/BlockingFDWNonModal2Test.java | 48 b/test/java/awt/Modal/ModalBlockingTests/BlockingFDWNonModal3Test.java | 48 b/test/java/awt/Modal/ModalBlockingTests/BlockingFDWNonModal4Test.java | 48 b/test/java/awt/Modal/ModalBlockingTests/BlockingFDWTest.java | 162 ++ b/test/java/awt/Modal/ModalBlockingTests/BlockingWindowsAppModal1Test.java | 49 b/test/java/awt/Modal/ModalBlockingTests/BlockingWindowsAppModal2Test.java | 49 b/test/java/awt/Modal/ModalBlockingTests/BlockingWindowsAppModal3Test.java | 49 b/test/java/awt/Modal/ModalBlockingTests/BlockingWindowsAppModal4Test.java | 49 b/test/java/awt/Modal/ModalBlockingTests/BlockingWindowsAppModal5Test.java | 49 b/test/java/awt/Modal/ModalBlockingTests/BlockingWindowsAppModal6Test.java | 49 b/test/java/awt/Modal/ModalBlockingTests/BlockingWindowsDocModal1Test.java | 49 b/test/java/awt/Modal/ModalBlockingTests/BlockingWindowsDocModal2Test.java | 49 b/test/java/awt/Modal/ModalBlockingTests/BlockingWindowsDocModalTest.java | 211 ++ b/test/java/awt/Modal/ModalBlockingTests/BlockingWindowsSetModal1Test.java | 48 b/test/java/awt/Modal/ModalBlockingTests/BlockingWindowsSetModal2Test.java | 48 b/test/java/awt/Modal/ModalBlockingTests/BlockingWindowsSetModal3Test.java | 48 b/test/java/awt/Modal/ModalBlockingTests/BlockingWindowsSetModal4Test.java | 48 b/test/java/awt/Modal/ModalBlockingTests/BlockingWindowsSetModal5Test.java | 48 b/test/java/awt/Modal/ModalBlockingTests/BlockingWindowsSetModal6Test.java | 48 b/test/java/awt/Modal/ModalBlockingTests/BlockingWindowsTest.java | 299 +++ b/test/java/awt/Modal/ModalBlockingTests/BlockingWindowsToolkitModal1Test.java | 49 b/test/java/awt/Modal/ModalBlockingTests/BlockingWindowsToolkitModal2Test.java | 49 b/test/java/awt/Modal/ModalBlockingTests/BlockingWindowsToolkitModal3Test.java | 49 b/test/java/awt/Modal/ModalBlockingTests/BlockingWindowsToolkitModal4Test.java | 49 b/test/java/awt/Modal/ModalBlockingTests/BlockingWindowsToolkitModal5Test.java | 49 b/test/java/awt/Modal/ModalBlockingTests/BlockingWindowsToolkitModal6Test.java | 49 b/test/java/awt/Modal/ModalBlockingTests/UnblockedDialogAppModalTest.java | 44 b/test/java/awt/Modal/ModalBlockingTests/UnblockedDialogDocModalTest.java | 44 b/test/java/awt/Modal/ModalBlockingTests/UnblockedDialogModelessTest.java | 44 b/test/java/awt/Modal/ModalBlockingTests/UnblockedDialogNonModalTest.java | 43 b/test/java/awt/Modal/ModalBlockingTests/UnblockedDialogSetModalTest.java | 43 b/test/java/awt/Modal/ModalBlockingTests/UnblockedDialogTest.java | 123 + b/test/java/awt/Modal/ModalBlockingTests/UnblockedDialogToolkitModalTest.java | 44 b/test/java/awt/Modal/ModalDialogOrderingTest/ModalDialogOrderingTest.java | 23 b/test/java/awt/Modal/ModalExclusionTests/ApplicationExcludeDialogFileTest.java | 49 b/test/java/awt/Modal/ModalExclusionTests/ApplicationExcludeDialogPageSetupTest.java | 49 b/test/java/awt/Modal/ModalExclusionTests/ApplicationExcludeDialogPrintSetupTest.java | 49 b/test/java/awt/Modal/ModalExclusionTests/ApplicationExcludeFrameFileTest.java | 50 b/test/java/awt/Modal/ModalExclusionTests/ApplicationExcludeFramePageSetupTest.java | 50 b/test/java/awt/Modal/ModalExclusionTests/ApplicationExcludeFramePrintSetupTest.java | 50 b/test/java/awt/Modal/ModalExclusionTests/ExcludeDialogTest.java | 199 ++ b/test/java/awt/Modal/ModalExclusionTests/ExcludeFrameTest.java | 192 ++ b/test/java/awt/Modal/ModalExclusionTests/ToolkitExcludeDialogFileTest.java | 50 b/test/java/awt/Modal/ModalExclusionTests/ToolkitExcludeDialogPageSetupTest.java | 50 b/test/java/awt/Modal/ModalExclusionTests/ToolkitExcludeDialogPrintSetupTest.java | 50 b/test/java/awt/Modal/ModalExclusionTests/ToolkitExcludeFrameFileTest.java | 50 b/test/java/awt/Modal/ModalExclusionTests/ToolkitExcludeFramePageSetupTest.java | 50 b/test/java/awt/Modal/ModalExclusionTests/ToolkitExcludeFramePrintSetupTest.java | 50 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDWFAppModalTest.java | 49 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDWFDocModalTest.java | 49 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDWFModelessTest.java | 49 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDWFNonModalTest.java | 48 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDWFTest.java | 186 ++ b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDialogsAppModalTest.java | 50 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDialogsDocModalTest.java | 50 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDialogsModelessTest.java | 50 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDialogsNonModalTest.java | 49 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDialogsTest.java | 193 ++ b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFDWAppModalTest.java | 49 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFDWDocModalTest.java | 49 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFDWModelessTest.java | 49 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFDWNonModalTest.java | 48 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFDWTest.java | 152 + b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDAppModal1Test.java | 50 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDAppModal2Test.java | 50 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDAppModal3Test.java | 50 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDAppModal4Test.java | 50 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDDocModal1Test.java | 50 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDDocModal2Test.java | 50 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDDocModal3Test.java | 50 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDDocModal4Test.java | 50 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDModeless1Test.java | 50 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDModeless2Test.java | 50 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDModeless3Test.java | 50 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDModeless4Test.java | 50 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDNonModal1Test.java | 49 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDNonModal2Test.java | 49 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDNonModal3Test.java | 49 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDNonModal4Test.java | 49 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDTest.java | 201 ++ b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFAppModal1Test.java | 51 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFAppModal2Test.java | 52 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFAppModal3Test.java | 52 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFDocModal1Test.java | 51 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFDocModal2Test.java | 52 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFDocModal3Test.java | 51 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFModeless1Test.java | 51 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFModeless2Test.java | 52 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFModeless3Test.java | 51 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFNonModal1Test.java | 51 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFNonModal2Test.java | 52 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFNonModal3Test.java | 51 b/test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFTest.java | 272 +++ b/test/java/awt/Modal/ModalInternalFrameTest/ModalInternalFrameTest.java | 9 b/test/java/awt/Modal/ModalitySettingsTest/ModalitySettingsTest.java | 139 + b/test/java/awt/Modal/MultipleDialogs/MultipleDialogs1Test.java | 209 ++ b/test/java/awt/Modal/MultipleDialogs/MultipleDialogs2Test.java | 299 +++ b/test/java/awt/Modal/MultipleDialogs/MultipleDialogs3Test.java | 286 +++ b/test/java/awt/Modal/MultipleDialogs/MultipleDialogs4Test.java | 178 ++ b/test/java/awt/Modal/MultipleDialogs/MultipleDialogs5Test.java | 184 ++ b/test/java/awt/Modal/NullModalityDialogTest/NullModalityDialogTest.java | 161 ++ b/test/java/awt/Modal/OnTop/OnTopAppModal1Test.java | 47 b/test/java/awt/Modal/OnTop/OnTopAppModal2Test.java | 47 b/test/java/awt/Modal/OnTop/OnTopAppModal3Test.java | 47 b/test/java/awt/Modal/OnTop/OnTopAppModal4Test.java | 47 b/test/java/awt/Modal/OnTop/OnTopAppModal5Test.java | 47 b/test/java/awt/Modal/OnTop/OnTopAppModal6Test.java | 46 b/test/java/awt/Modal/OnTop/OnTopDDFTest.java | 169 ++ b/test/java/awt/Modal/OnTop/OnTopDocModal1Test.java | 47 b/test/java/awt/Modal/OnTop/OnTopDocModal2Test.java | 47 b/test/java/awt/Modal/OnTop/OnTopDocModal3Test.java | 47 b/test/java/awt/Modal/OnTop/OnTopDocModal4Test.java | 47 b/test/java/awt/Modal/OnTop/OnTopDocModal5Test.java | 47 b/test/java/awt/Modal/OnTop/OnTopDocModal6Test.java | 45 b/test/java/awt/Modal/OnTop/OnTopFDFTest.java | 230 ++ b/test/java/awt/Modal/OnTop/OnTopModal1Test.java | 46 b/test/java/awt/Modal/OnTop/OnTopModal2Test.java | 46 b/test/java/awt/Modal/OnTop/OnTopModal3Test.java | 46 b/test/java/awt/Modal/OnTop/OnTopModal4Test.java | 46 b/test/java/awt/Modal/OnTop/OnTopModal5Test.java | 46 b/test/java/awt/Modal/OnTop/OnTopModal6Test.java | 45 b/test/java/awt/Modal/OnTop/OnTopModeless1Test.java | 47 b/test/java/awt/Modal/OnTop/OnTopModeless2Test.java | 47 b/test/java/awt/Modal/OnTop/OnTopModeless3Test.java | 47 b/test/java/awt/Modal/OnTop/OnTopModeless4Test.java | 47 b/test/java/awt/Modal/OnTop/OnTopModeless5Test.java | 47 b/test/java/awt/Modal/OnTop/OnTopModeless6Test.java | 45 b/test/java/awt/Modal/OnTop/OnTopTKModal1Test.java | 47 b/test/java/awt/Modal/OnTop/OnTopTKModal2Test.java | 47 b/test/java/awt/Modal/OnTop/OnTopTKModal3Test.java | 47 b/test/java/awt/Modal/OnTop/OnTopTKModal4Test.java | 47 b/test/java/awt/Modal/OnTop/OnTopTKModal5Test.java | 47 b/test/java/awt/Modal/OnTop/OnTopTKModal6Test.java | 45 b/test/java/awt/Modal/PrintDialogsTest/PrintDialogsTest.html | 44 b/test/java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java | 160 ++ b/test/java/awt/Modal/PrintDialogsTest/Test.java | 217 ++ b/test/java/awt/Modal/ToBack/ToBackAppModal1Test.java | 47 b/test/java/awt/Modal/ToBack/ToBackAppModal2Test.java | 47 b/test/java/awt/Modal/ToBack/ToBackAppModal3Test.java | 47 b/test/java/awt/Modal/ToBack/ToBackAppModal4Test.java | 47 b/test/java/awt/Modal/ToBack/ToBackAppModal5Test.java | 47 b/test/java/awt/Modal/ToBack/ToBackAppModal6Test.java | 46 b/test/java/awt/Modal/ToBack/ToBackDDFTest.java | 183 ++ b/test/java/awt/Modal/ToBack/ToBackDocModal1Test.java | 46 b/test/java/awt/Modal/ToBack/ToBackDocModal2Test.java | 46 b/test/java/awt/Modal/ToBack/ToBackDocModal3Test.java | 46 b/test/java/awt/Modal/ToBack/ToBackDocModal4Test.java | 46 b/test/java/awt/Modal/ToBack/ToBackDocModal5Test.java | 47 b/test/java/awt/Modal/ToBack/ToBackDocModal6Test.java | 46 b/test/java/awt/Modal/ToBack/ToBackFDFTest.java | 291 +++ b/test/java/awt/Modal/ToBack/ToBackModal1Test.java | 47 b/test/java/awt/Modal/ToBack/ToBackModal2Test.java | 46 b/test/java/awt/Modal/ToBack/ToBackModal3Test.java | 46 b/test/java/awt/Modal/ToBack/ToBackModal4Test.java | 46 b/test/java/awt/Modal/ToBack/ToBackModal5Test.java | 46 b/test/java/awt/Modal/ToBack/ToBackModal6Test.java | 45 b/test/java/awt/Modal/ToBack/ToBackModeless1Test.java | 46 b/test/java/awt/Modal/ToBack/ToBackModeless2Test.java | 46 b/test/java/awt/Modal/ToBack/ToBackModeless3Test.java | 46 b/test/java/awt/Modal/ToBack/ToBackModeless4Test.java | 46 b/test/java/awt/Modal/ToBack/ToBackModeless5Test.java | 46 b/test/java/awt/Modal/ToBack/ToBackModeless6Test.java | 45 b/test/java/awt/Modal/ToBack/ToBackNonModal1Test.java | 46 b/test/java/awt/Modal/ToBack/ToBackNonModal2Test.java | 45 b/test/java/awt/Modal/ToBack/ToBackNonModal3Test.java | 45 b/test/java/awt/Modal/ToBack/ToBackNonModal4Test.java | 45 b/test/java/awt/Modal/ToBack/ToBackNonModal5Test.java | 45 b/test/java/awt/Modal/ToBack/ToBackNonModal6Test.java | 44 b/test/java/awt/Modal/ToBack/ToBackTKModal1Test.java | 47 b/test/java/awt/Modal/ToBack/ToBackTKModal2Test.java | 47 b/test/java/awt/Modal/ToBack/ToBackTKModal3Test.java | 47 b/test/java/awt/Modal/ToBack/ToBackTKModal4Test.java | 47 b/test/java/awt/Modal/ToBack/ToBackTKModal5Test.java | 47 b/test/java/awt/Modal/ToBack/ToBackTKModal6Test.java | 46 b/test/java/awt/Modal/ToFront/DialogToFrontAppModalTest.java | 47 b/test/java/awt/Modal/ToFront/DialogToFrontDocModalTest.java | 47 b/test/java/awt/Modal/ToFront/DialogToFrontModalBlockedTest.java | 135 + b/test/java/awt/Modal/ToFront/DialogToFrontModalTest.java | 44 b/test/java/awt/Modal/ToFront/DialogToFrontModeless1Test.java | 43 b/test/java/awt/Modal/ToFront/DialogToFrontModelessTest.java | 105 + b/test/java/awt/Modal/ToFront/DialogToFrontNonModalTest.java | 43 b/test/java/awt/Modal/ToFront/DialogToFrontTKModalTest.java | 47 b/test/java/awt/Modal/ToFront/FrameToFrontAppModal1Test.java | 48 b/test/java/awt/Modal/ToFront/FrameToFrontAppModal2Test.java | 48 b/test/java/awt/Modal/ToFront/FrameToFrontAppModal3Test.java | 48 b/test/java/awt/Modal/ToFront/FrameToFrontAppModal4Test.java | 48 b/test/java/awt/Modal/ToFront/FrameToFrontAppModal5Test.java | 48 b/test/java/awt/Modal/ToFront/FrameToFrontDocModal1Test.java | 48 b/test/java/awt/Modal/ToFront/FrameToFrontDocModal2Test.java | 53 b/test/java/awt/Modal/ToFront/FrameToFrontModal1Test.java | 46 b/test/java/awt/Modal/ToFront/FrameToFrontModal2Test.java | 46 b/test/java/awt/Modal/ToFront/FrameToFrontModal3Test.java | 46 b/test/java/awt/Modal/ToFront/FrameToFrontModal4Test.java | 46 b/test/java/awt/Modal/ToFront/FrameToFrontModal5Test.java | 46 b/test/java/awt/Modal/ToFront/FrameToFrontModalBlockedTest.java | 207 ++ b/test/java/awt/Modal/ToFront/FrameToFrontModeless1Test.java | 44 b/test/java/awt/Modal/ToFront/FrameToFrontModelessTest.java | 98 + b/test/java/awt/Modal/ToFront/FrameToFrontNonModalTest.java | 44 b/test/java/awt/Modal/ToFront/FrameToFrontTKModal1Test.java | 48 b/test/java/awt/Modal/ToFront/FrameToFrontTKModal2Test.java | 48 b/test/java/awt/Modal/ToFront/FrameToFrontTKModal3Test.java | 48 b/test/java/awt/Modal/ToFront/FrameToFrontTKModal4Test.java | 48 b/test/java/awt/Modal/ToFront/FrameToFrontTKModal5Test.java | 48 b/test/java/awt/Modal/helpers/Flag.java | 84 + b/test/java/awt/Modal/helpers/TestDialog.java | 405 +++++ b/test/java/awt/Modal/helpers/TestFrame.java | 400 +++++ b/test/java/awt/Modal/helpers/TestWindow.java | 369 ++++ b/test/java/awt/Mouse/EnterExitEvents/DragWindowOutOfFrameTest.java | 14 b/test/java/awt/Mouse/EnterExitEvents/DragWindowTest.java | 10 b/test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java | 44 b/test/java/awt/Mouse/MaximizedFrameTest/MaximizedFrameTest.java | 200 +- b/test/java/awt/Mouse/MouseComboBoxTest/MouseComboBoxTest.java | 10 b/test/java/awt/Multiscreen/MouseEventTest/MouseEventTest.java | 10 b/test/java/awt/Paint/ExposeOnEDT.java | 17 b/test/java/awt/Paint/PaintNativeOnUpdate.java | 25 b/test/java/awt/Robot/CtorTest/CtorTest.java | 6 b/test/java/awt/ScrollPane/ScrollPanePreferredSize/ScrollPanePreferredSize.java | 13 b/test/java/awt/TextArea/DisposeTest/TestDispose.java | 17 b/test/java/awt/TextArea/ScrollbarIntersectionTest/ScrollbarIntersectionTest.java | 207 ++ b/test/java/awt/TextArea/TextAreaCaretVisibilityTest/bug7129742.java | 7 b/test/java/awt/TextArea/TextAreaTwicePack/TextAreaTwicePack.java | 9 b/test/java/awt/TextField/DisposeTest/TestDispose.java | 16 b/test/java/awt/TextField/SelectionInvisibleTest/SelectionInvisibleTest.java | 11 b/test/java/awt/Toolkit/DesktopProperties/rfe4758438.java | 238 ++ b/test/java/awt/Toolkit/DesktopProperties/rfe4758438.sh | 83 + b/test/java/awt/Toolkit/Headless/HeadlessToolkit.java | 329 ++++ b/test/java/awt/Toolkit/RealSync/Test.java | 405 +++++ b/test/java/awt/TrayIcon/ActionCommand/ActionCommand.java | 162 ++ b/test/java/awt/TrayIcon/ActionEventMask/ActionEventMask.java | 252 +++ b/test/java/awt/TrayIcon/GetTrayIconsTest/GetTrayIcons.java | 86 + b/test/java/awt/TrayIcon/InterJVMTest/InterJVM.java | 86 + b/test/java/awt/TrayIcon/ModalityTest/ModalityTest.java | 302 +++ b/test/java/awt/TrayIcon/MouseEventMask/MouseEventMaskTest.java | 195 ++ b/test/java/awt/TrayIcon/MouseMovedTest/MouseMovedTest.java | 64 b/test/java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java | 10 b/test/java/awt/TrayIcon/PropertyChangeListenerTest.java | 201 ++ b/test/java/awt/TrayIcon/SecurityCheck/FunctionalityCheck/FunctionalityCheck.java | 263 +++ b/test/java/awt/TrayIcon/SecurityCheck/FunctionalityCheck/tray.policy | 21 b/test/java/awt/TrayIcon/SecurityCheck/NoPermissionTest/NoPermissionTest.java | 64 b/test/java/awt/TrayIcon/SecurityCheck/NoPermissionTest/tray.policy | 3 b/test/java/awt/TrayIcon/SecurityCheck/PermissionTest/PermissionTest.java | 50 b/test/java/awt/TrayIcon/SecurityCheck/PermissionTest/tray.policy | 3 b/test/java/awt/TrayIcon/SystemTrayIconHelper.java | 172 ++ b/test/java/awt/TrayIcon/SystemTrayInstance/SystemTrayInstanceTest.java | 71 b/test/java/awt/TrayIcon/TrayIconAddTest/TrayIconAddTest.java | 66 b/test/java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java | 275 +++ b/test/java/awt/TrayIcon/TrayIconEvents/TrayIconEventsTest.java | 269 +++ b/test/java/awt/TrayIcon/TrayIconMethodsTest/TrayIconMethodsTest.java | 159 ++ b/test/java/awt/TrayIcon/TrayIconMouseTest/TrayIconMouseTest.java | 176 ++ b/test/java/awt/TrayIcon/TrayIconPopup/TrayIconPopupTest.java | 151 + b/test/java/awt/TrayIcon/TrayIconRemoveTest/TrayIconRemoveTest.java | 72 b/test/java/awt/TrayIcon/TrayIconSizeTest/TrayIconSizeTest.java | 69 b/test/java/awt/Window/8027025/Test8027025.java | 5 b/test/java/awt/Window/AlwaysOnTop/AlwaysOnTopFieldTest.java | 21 b/test/java/awt/Window/AlwaysOnTop/AutoTestOnTop.java | 795 ++++++++++ b/test/java/awt/Window/AlwaysOnTop/TestAlwaysOnTopBeforeShow.java | 9 b/test/java/awt/Window/BackgroundIsNotUpdated/BackgroundIsNotUpdated.java | 23 b/test/java/awt/Window/GetWindowsTest/GetWindowsTest.java | 271 +++ b/test/java/awt/Window/HandleWindowDestroyTest/HandleWindowDestroyTest.html | 23 b/test/java/awt/Window/HandleWindowDestroyTest/HandleWindowDestroyTest.java | 96 + b/test/java/awt/Window/OwnedWindowsSerialization/OwnedWindowsSerialization.java | 5 b/test/java/awt/Window/ShapedAndTranslucentWindows/FocusAWTTest.java | 14 b/test/java/awt/Window/ShapedAndTranslucentWindows/SetShape.java | 250 +++ b/test/java/awt/Window/ShapedAndTranslucentWindows/SetShapeAndClick.java | 216 ++ b/test/java/awt/Window/ShapedAndTranslucentWindows/SetShapeDynamicallyAndClick.java | 214 ++ b/test/java/awt/Window/ShapedAndTranslucentWindows/Shaped.java | 21 b/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedByAPI.java | 20 b/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java | 16 b/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucentWindowClick.java | 210 ++ b/test/java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java | 20 b/test/java/awt/Window/ShapedAndTranslucentWindows/Translucent.java | 19 b/test/java/awt/Window/ShapedAndTranslucentWindows/TranslucentChoice.java | 186 ++ b/test/java/awt/Window/ShapedAndTranslucentWindows/TranslucentWindowClick.java | 152 + b/test/java/awt/Window/TranslucentJAppletTest/TranslucentJAppletTest.java | 3 b/test/java/awt/Window/setLocRelativeTo/SetLocationRelativeToTest.java | 293 +++ b/test/java/awt/applet/Applet/HeadlessApplet.java | 49 b/test/java/awt/datatransfer/Clipboard/BasicClipboardTest.java | 138 + b/test/java/awt/datatransfer/Clipboard/GetContentsInterruptedTest.java | 164 ++ b/test/java/awt/datatransfer/DataFlavor/DataFlavorCloneTest/DataFlavorCloneTest.java | 49 b/test/java/awt/datatransfer/DataFlavor/DataFlavorEqualsNullTest.java | 62 b/test/java/awt/datatransfer/DataFlavor/DataFlavorEqualsTest.java | 58 b/test/java/awt/datatransfer/DataFlavor/DataFlavorFileListTest.java | 45 b/test/java/awt/datatransfer/DataFlavor/DataFlavorSerializedTest.java | 46 b/test/java/awt/datatransfer/DataFlavor/DefaultMatchTest.java | 64 b/test/java/awt/datatransfer/DataFlavor/EqualHashCodeTest.java | 83 + b/test/java/awt/datatransfer/DataFlavor/ExternalizeTest.java | 80 + b/test/java/awt/datatransfer/DataFlavor/GetReaderForTextIAEForStringSelectionTest.java | 70 b/test/java/awt/datatransfer/DataFlavor/GetReaderForTextNPETest.java | 74 b/test/java/awt/datatransfer/DataFlavor/MimeTypeSerializationTest.java | 86 + b/test/java/awt/datatransfer/DataFlavor/NoClassParameterTest.java | 50 b/test/java/awt/datatransfer/DataFlavor/NormalizeMimeTypeParameter.java | 60 b/test/java/awt/datatransfer/DataFlavor/NullDataFlavorTest.java | 108 + b/test/java/awt/datatransfer/DataFlavor/ReaderForUnicodeText.java | 90 + b/test/java/awt/datatransfer/DataFlavor/SelectBestFlavorNPETest.java | 50 b/test/java/awt/datatransfer/DataFlavor/SelectBestTextFlavorBadArrayTest.java | 73 b/test/java/awt/datatransfer/DataFlavor/ToStringNullPointerTest.java | 47 b/test/java/awt/datatransfer/Headless/HeadlessClipboard.java | 38 b/test/java/awt/datatransfer/Headless/HeadlessDataFlavor.java | 43 b/test/java/awt/datatransfer/Headless/HeadlessSystemFlavorMap.java | 38 b/test/java/awt/datatransfer/ImageTransfer/ImageTransferTest.java | 189 ++ b/test/java/awt/datatransfer/Independence/IndependenceAWTTest.java | 188 ++ b/test/java/awt/datatransfer/Independence/IndependenceSwingTest.java | 195 ++ b/test/java/awt/datatransfer/MissedHtmlAndRtfBug/AbsoluteComponentCenterCalculator.java | 37 b/test/java/awt/datatransfer/MissedHtmlAndRtfBug/DataFlavorSearcher.java | 47 b/test/java/awt/datatransfer/MissedHtmlAndRtfBug/InterprocessMessages.java | 29 b/test/java/awt/datatransfer/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.html | 48 b/test/java/awt/datatransfer/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.java | 199 ++ b/test/java/awt/datatransfer/MissedHtmlAndRtfBug/MyTransferable.java | 62 b/test/java/awt/datatransfer/MissedHtmlAndRtfBug/NextFramePositionCalculator.java | 43 b/test/java/awt/datatransfer/MissedHtmlAndRtfBug/SourcePanel.java | 49 b/test/java/awt/datatransfer/MissedHtmlAndRtfBug/TargetPanel.java | 106 + b/test/java/awt/datatransfer/SystemFlavorMap/AddFlavorForNativeTest.java | 154 + b/test/java/awt/datatransfer/SystemFlavorMap/AddFlavorTest.java | 146 + b/test/java/awt/datatransfer/SystemFlavorMap/AddNativeForFlavorTest.java | 156 + b/test/java/awt/datatransfer/SystemFlavorMap/AddNativeTest.java | 144 + b/test/java/awt/datatransfer/SystemFlavorMap/DuplicateMappingTest.java | 94 + b/test/java/awt/datatransfer/SystemFlavorMap/DuplicatedNativesTest.java | 57 b/test/java/awt/datatransfer/SystemFlavorMap/GetFlavorsForNewNativeTest.java | 130 + b/test/java/awt/datatransfer/SystemFlavorMap/GetNativesForFlavorTest.java | 169 ++ b/test/java/awt/datatransfer/SystemFlavorMap/GetNativesForNewFlavorTest.java | 111 + b/test/java/awt/datatransfer/SystemFlavorMap/InvalidMapArgumentsTest.java | 139 + b/test/java/awt/datatransfer/SystemFlavorMap/ManyFlavorMapTest.java | 182 ++ b/test/java/awt/datatransfer/SystemFlavorMap/MappingGenerationTest.java | 183 ++ b/test/java/awt/datatransfer/SystemFlavorMap/SetDataFlavorsTest.java | 131 + b/test/java/awt/datatransfer/SystemFlavorMap/SetFlavorsForNativeTest.java | 165 ++ b/test/java/awt/datatransfer/SystemFlavorMap/SetNativesForFlavor.java | 164 ++ b/test/java/awt/datatransfer/SystemFlavorMap/SetNativesForFlavorTest.java | 67 b/test/java/awt/datatransfer/SystemFlavorMap/SetNativesTest.java | 122 + b/test/java/awt/datatransfer/SystemSelection/SystemSelectionAWTTest.java | 171 ++ b/test/java/awt/datatransfer/SystemSelection/SystemSelectionSwingTest.java | 173 ++ b/test/java/awt/dnd/ImageTransferTest/ImageTransferTest.java | 14 b/test/java/awt/dnd/MissingDragExitEventTest/MissingDragExitEventTest.java | 8 b/test/java/awt/event/ComponentEvent/MovedResizedTardyEventTest/MovedResizedTardyEventTest.html | 43 b/test/java/awt/event/ComponentEvent/MovedResizedTardyEventTest/MovedResizedTardyEventTest.java | 97 + b/test/java/awt/event/ComponentEvent/MovedResizedTwiceTest/MovedResizedTwiceTest.java | 276 +++ b/test/java/awt/event/InputEvent/EventWhenTest/EventWhenTest.java | 7 b/test/java/awt/event/KeyEvent/8020209/bug8020209.java | 12 b/test/java/awt/event/KeyEvent/AltCharAcceleratorTest/AltCharAcceleratorTest.java | 11 b/test/java/awt/event/KeyEvent/DeadKey/DeadKeyMacOSXInputText.java | 18 b/test/java/awt/event/KeyEvent/DeadKey/DeadKeySystemAssertionDialog.java | 14 b/test/java/awt/event/KeyEvent/DeadKey/deadKeyMacOSX.java | 16 b/test/java/awt/event/KeyEvent/ExtendedKeyCode/ExtendedKeyCodeTest.java | 20 b/test/java/awt/event/KeyEvent/ExtendedModifiersTest/ExtendedModifiersTest.java | 271 +++ b/test/java/awt/event/KeyEvent/KeyChar/KeyCharTest.java | 9 b/test/java/awt/event/KeyEvent/KeyMaskTest/KeyMaskTest.java | 219 ++ b/test/java/awt/event/MouseEvent/ClickDuringKeypress/ClickDuringKeypress.java | 163 ++ b/test/java/awt/event/MouseEvent/MouseButtonsAndKeyMasksTest/MouseButtonsAndKeyMasksTest.java | 302 +++ b/test/java/awt/event/MouseEvent/MouseButtonsTest/MouseButtonsTest.java | 254 +++ b/test/java/awt/event/MouseEvent/MultipleMouseButtonsTest/MultipleMouseButtonsTest.java | 237 ++ b/test/java/awt/event/MouseWheelEvent/DisabledComponent/DisabledComponent.java | 18 b/test/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest.java | 34 b/test/java/awt/event/helpers/lwcomponents/LWButton.java | 418 +++++ b/test/java/awt/event/helpers/lwcomponents/LWComponent.java | 464 +++++ b/test/java/awt/event/helpers/lwcomponents/LWList.java | 726 +++++++++ b/test/java/awt/grab/EmbeddedFrameTest1/EmbeddedFrameTest1.java | 299 --- b/test/java/awt/grab/MenuDragEvents/MenuDragEvents.html | 44 b/test/java/awt/grab/MenuDragEvents/MenuDragEvents.java | 195 ++ b/test/java/awt/im/Headless/HeadlessInputContext.java | 43 b/test/java/awt/im/Headless/HeadlessInputMethodHighlight.java | 41 b/test/java/awt/image/Headless/HeadlessAffineTransformOp.java | 44 b/test/java/awt/image/Headless/HeadlessAreaAveragingScaleFilter.java | 37 b/test/java/awt/image/Headless/HeadlessBufferedImage.java | 80 + b/test/java/awt/image/Headless/HeadlessBufferedImageFilter.java | 38 b/test/java/awt/image/Headless/HeadlessColorModel.java | 61 b/test/java/awt/image/Headless/HeadlessCropImageFilter.java | 37 b/test/java/awt/image/Headless/HeadlessImageFilter.java | 37 b/test/java/awt/image/Headless/HeadlessIndexColorModel.java | 54 b/test/java/awt/image/Headless/HeadlessRGBImageFilter.java | 42 b/test/java/awt/image/Headless/HeadlessReplicateScaleFilter.java | 37 b/test/java/awt/keyboard/AltPlusNumberKeyCombinationsTest/AltPlusNumberKeyCombinationsTest.java | 307 +++ b/test/java/awt/keyboard/EqualKeyCode/EqualKeyCode.java | 16 b/test/java/awt/print/Headless/HeadlessBook.java | 37 b/test/java/awt/print/Headless/HeadlessPageFormat.java | 61 b/test/java/awt/print/Headless/HeadlessPaper.java | 46 b/test/java/awt/print/Headless/HeadlessPrinterJob.java | 179 ++ b/test/java/awt/regtesthelpers/Util.java | 51 b/test/java/awt/regtesthelpers/UtilInternal.java | 77 b/test/java/util/concurrent/forkjoin/AccessControlContext.java | 10 b/test/javax/swing/AbstractButton/6711682/bug6711682.java | 5 b/test/javax/swing/Headless/HeadlessAbstractSpinnerModel.java | 46 b/test/javax/swing/Headless/HeadlessBox.java | 221 ++ b/test/javax/swing/Headless/HeadlessBox_Filler.java | 194 ++ b/test/javax/swing/Headless/HeadlessCellRendererPane.java | 202 ++ b/test/javax/swing/Headless/HeadlessDefaultListCellRenderer.java | 198 ++ b/test/javax/swing/Headless/HeadlessDefaultListCellRenderer_UIResource.java | 198 ++ b/test/javax/swing/Headless/HeadlessGrayFilter.java | 37 b/test/javax/swing/Headless/HeadlessJApplet.java | 44 b/test/javax/swing/Headless/HeadlessJButton.java | 192 ++ b/test/javax/swing/Headless/HeadlessJCheckBox.java | 195 ++ b/test/javax/swing/Headless/HeadlessJCheckBoxMenuItem.java | 192 ++ b/test/javax/swing/Headless/HeadlessJColorChooser.java | 192 ++ b/test/javax/swing/Headless/HeadlessJComboBox.java | 192 ++ b/test/javax/swing/Headless/HeadlessJComponent.java | 191 ++ b/test/javax/swing/Headless/HeadlessJDesktopPane.java | 191 ++ b/test/javax/swing/Headless/HeadlessJDialog.java | 100 + b/test/javax/swing/Headless/HeadlessJEditorPane.java | 194 ++ b/test/javax/swing/Headless/HeadlessJFileChooser.java | 191 ++ b/test/javax/swing/Headless/HeadlessJFormattedTextField.java | 41 b/test/javax/swing/Headless/HeadlessJFrame.java | 53 b/test/javax/swing/Headless/HeadlessJInternalFrame.java | 214 ++ b/test/javax/swing/Headless/HeadlessJInternalFrame_JDesktopIcon.java | 191 ++ b/test/javax/swing/Headless/HeadlessJLabel.java | 191 ++ b/test/javax/swing/Headless/HeadlessJLayeredPane.java | 191 ++ b/test/javax/swing/Headless/HeadlessJList.java | 191 ++ b/test/javax/swing/Headless/HeadlessJMenu.java | 189 ++ b/test/javax/swing/Headless/HeadlessJMenuBar.java | 191 ++ b/test/javax/swing/Headless/HeadlessJMenuItem.java | 191 ++ b/test/javax/swing/Headless/HeadlessJOptionPane.java | 191 ++ b/test/javax/swing/Headless/HeadlessJPanel.java | 191 ++ b/test/javax/swing/Headless/HeadlessJPasswordField.java | 40 b/test/javax/swing/Headless/HeadlessJPopupMenu.java | 189 ++ b/test/javax/swing/Headless/HeadlessJPopupMenu_Separator.java | 191 ++ b/test/javax/swing/Headless/HeadlessJProgressBar.java | 191 ++ b/test/javax/swing/Headless/HeadlessJRadioButton.java | 191 ++ b/test/javax/swing/Headless/HeadlessJRadioButtonMenuItem.java | 191 ++ b/test/javax/swing/Headless/HeadlessJRootPane.java | 191 ++ b/test/javax/swing/Headless/HeadlessJScrollBar.java | 191 ++ b/test/javax/swing/Headless/HeadlessJScrollPane.java | 191 ++ b/test/javax/swing/Headless/HeadlessJSeparator.java | 191 ++ b/test/javax/swing/Headless/HeadlessJSlider.java | 191 ++ b/test/javax/swing/Headless/HeadlessJSpinner.java | 191 ++ b/test/javax/swing/Headless/HeadlessJSplitPane.java | 185 ++ b/test/javax/swing/Headless/HeadlessJTabbedPane.java | 191 ++ b/test/javax/swing/Headless/HeadlessJTable.java | 214 ++ b/test/javax/swing/Headless/HeadlessJTextArea.java | 195 ++ b/test/javax/swing/Headless/HeadlessJTextField.java | 195 ++ b/test/javax/swing/Headless/HeadlessJTextPane.java | 45 b/test/javax/swing/Headless/HeadlessJToggleButton.java | 191 ++ b/test/javax/swing/Headless/HeadlessJToolBar.java | 191 ++ b/test/javax/swing/Headless/HeadlessJToolBar_Separator.java | 191 ++ b/test/javax/swing/Headless/HeadlessJToolTip.java | 191 ++ b/test/javax/swing/Headless/HeadlessJTree.java | 232 ++ b/test/javax/swing/Headless/HeadlessJViewport.java | 199 ++ b/test/javax/swing/Headless/HeadlessJWindow.java | 56 b/test/javax/swing/Headless/HeadlessLookAndFeel.java | 37 b/test/javax/swing/Headless/HeadlessMenuSelectionManager.java | 38 b/test/javax/swing/Headless/HeadlessOverlayLayout.java | 38 b/test/javax/swing/Headless/HeadlessPopupFactory.java | 37 b/test/javax/swing/Headless/HeadlessScrollPaneLayout.java | 37 b/test/javax/swing/Headless/HeadlessSizeRequirements.java | 39 b/test/javax/swing/Headless/HeadlessSizeSequence.java | 41 b/test/javax/swing/Headless/HeadlessSpinnerListModel.java | 49 b/test/javax/swing/Headless/HeadlessSpinnerNumberModel.java | 41 b/test/javax/swing/Headless/HeadlessTimer.java | 37 b/test/javax/swing/JButton/4368790/bug4368790.java | 71 b/test/javax/swing/JButton/JButtonPaintNPE/JButtonPaintNPE.java | 15 b/test/javax/swing/JColorChooser/Test4319113.html | 39 b/test/javax/swing/JColorChooser/Test4319113.java | 128 + b/test/javax/swing/JColorChooser/Test6541987.java | 9 b/test/javax/swing/JColorChooser/Test6827032.java | 5 b/test/javax/swing/JColorChooser/Test7194184.java | 9 b/test/javax/swing/JComboBox/4199622/bug4199622.java | 38 b/test/javax/swing/JComboBox/4515752/DefaultButtonTest.java | 214 ++ b/test/javax/swing/JComboBox/4523758/bug4523758.java | 182 ++ b/test/javax/swing/JComboBox/4743225/bug4743225.java | 8 b/test/javax/swing/JComboBox/6236162/bug6236162.java | 15 b/test/javax/swing/JComboBox/6406264/bug6406264.java | 118 + b/test/javax/swing/JComboBox/6559152/bug6559152.java | 101 + b/test/javax/swing/JComboBox/6607130/bug6607130.java | 32 b/test/javax/swing/JComboBox/8015300/Test8015300.java | 17 b/test/javax/swing/JComboBox/8032878/bug8032878.java | 12 b/test/javax/swing/JComboBox/8057893/bug8057893.java | 6 b/test/javax/swing/JComboBox/ShowPopupAfterHidePopupTest/ShowPopupAfterHidePopupTest.java | 9 b/test/javax/swing/JComponent/6683775/bug6683775.java | 4 b/test/javax/swing/JComponent/6989617/bug6989617.java | 12 b/test/javax/swing/JComponent/7154030/bug7154030.java | 21 b/test/javax/swing/JEditorPane/4492274/bug4492274.java | 9 b/test/javax/swing/JEditorPane/6917744/bug6917744.java | 13 b/test/javax/swing/JFileChooser/4524490/bug4524490.java | 11 b/test/javax/swing/JFileChooser/7199708/bug7199708.java | 8 b/test/javax/swing/JFileChooser/8002077/bug8002077.java | 13 b/test/javax/swing/JFileChooser/8021253/bug8021253.java | 8 b/test/javax/swing/JFrame/4962534/bug4962534.java | 10 b/test/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java | 23 b/test/javax/swing/JInternalFrame/4251301/bug4251301.java | 9 b/test/javax/swing/JInternalFrame/5066752/bug5066752.java | 4 b/test/javax/swing/JInternalFrame/6647340/bug6647340.java | 31 b/test/javax/swing/JInternalFrame/6725409/bug6725409.java | 23 b/test/javax/swing/JInternalFrame/8020708/bug8020708.java | 13 b/test/javax/swing/JInternalFrame/InternalFrameIsNotCollectedTest.java | 12 b/test/javax/swing/JLabel/6596966/bug6596966.java | 25 b/test/javax/swing/JLayer/6824395/bug6824395.java | 12 b/test/javax/swing/JList/6462008/bug6462008.java | 69 b/test/javax/swing/JList/6510999/bug6510999.java | 74 b/test/javax/swing/JMenu/4417601/bug4417601.java | 79 b/test/javax/swing/JMenu/4515762/bug4515762.java | 18 b/test/javax/swing/JMenu/4692443/bug4692443.java | 35 b/test/javax/swing/JMenu/6359669/bug6359669.java | 84 + b/test/javax/swing/JMenu/6470128/bug6470128.java | 84 + b/test/javax/swing/JMenu/6538132/bug6538132.java | 131 + b/test/javax/swing/JMenuBar/4750590/bug4750590.java | 7 b/test/javax/swing/JMenuItem/4171437/bug4171437.java | 7 b/test/javax/swing/JMenuItem/4654927/bug4654927.java | 12 b/test/javax/swing/JMenuItem/6209975/bug6209975.java | 10 b/test/javax/swing/JMenuItem/6249972/bug6249972.java | 105 + b/test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java | 9 b/test/javax/swing/JOptionPane/4174551/bug4174551.html | 36 b/test/javax/swing/JOptionPane/4174551/bug4174551.java | 52 b/test/javax/swing/JOptionPane/6428694/bug6428694.java | 114 + b/test/javax/swing/JOptionPane/7138665/bug7138665.java | 10 b/test/javax/swing/JPopupMenu/4458079/bug4458079.java | 10 b/test/javax/swing/JPopupMenu/4634626/bug4634626.html | 8 b/test/javax/swing/JPopupMenu/4634626/bug4634626.java | 205 ++ b/test/javax/swing/JPopupMenu/4966112/bug4966112.java | 22 b/test/javax/swing/JPopupMenu/6217905/bug6217905.java | 114 + b/test/javax/swing/JPopupMenu/6415145/bug6415145.java | 121 + b/test/javax/swing/JPopupMenu/6515446/bug6515446.java | 91 + b/test/javax/swing/JPopupMenu/6544309/bug6544309.java | 105 + b/test/javax/swing/JPopupMenu/6580930/bug6580930.java | 148 + b/test/javax/swing/JPopupMenu/6583251/bug6583251.java | 77 b/test/javax/swing/JPopupMenu/6691503/bug6691503.java | 10 b/test/javax/swing/JPopupMenu/6694823/bug6694823.java | 18 b/test/javax/swing/JPopupMenu/6800513/bug6800513.java | 12 b/test/javax/swing/JPopupMenu/6827786/bug6827786.java | 12 b/test/javax/swing/JPopupMenu/6987844/bug6987844.java | 7 b/test/javax/swing/JPopupMenu/7154841/bug7154841.java | 19 b/test/javax/swing/JRadioButton/8033699/bug8033699.java | 7 b/test/javax/swing/JRootPane/4670486/bug4670486.java | 8 b/test/javax/swing/JScrollBar/4708809/bug4708809.java | 14 b/test/javax/swing/JScrollBar/4865918/bug4865918.java | 7 b/test/javax/swing/JScrollBar/6542335/bug6542335.java | 8 b/test/javax/swing/JScrollBar/7163696/Test7163696.java | 8 b/test/javax/swing/JScrollBar/bug4202954/bug4202954.java | 12 b/test/javax/swing/JScrollPane/6274267/bug6274267.java | 100 + b/test/javax/swing/JSlider/6348946/bug6348946.java | 14 b/test/javax/swing/JSlider/6401380/bug6401380.java | 82 + b/test/javax/swing/JSlider/6848475/bug6848475.java | 9 b/test/javax/swing/JSpinner/4973721/bug4973721.java | 7 b/test/javax/swing/JSpinner/5012888/bug5012888.java | 4 b/test/javax/swing/JSpinner/8008657/bug8008657.java | 17 b/test/javax/swing/JSplitPane/4816114/bug4816114.java | 7 b/test/javax/swing/JSplitPane/4885629/bug4885629.java | 5 b/test/javax/swing/JTabbedPane/4361477/bug4361477.java | 4 b/test/javax/swing/JTabbedPane/4624207/bug4624207.java | 15 b/test/javax/swing/JTabbedPane/4666224/bug4666224.html | 42 b/test/javax/swing/JTabbedPane/4666224/bug4666224.java | 554 ++++++ b/test/javax/swing/JTabbedPane/6495408/bug6495408.java | 4 b/test/javax/swing/JTabbedPane/7024235/Test7024235.java | 14 b/test/javax/swing/JTabbedPane/7161568/bug7161568.java | 8 b/test/javax/swing/JTabbedPane/7170310/bug7170310.java | 17 b/test/javax/swing/JTable/4220171/bug4220171.java | 13 b/test/javax/swing/JTable/6263446/bug6263446.java | 34 b/test/javax/swing/JTable/6777378/bug6777378.java | 5 b/test/javax/swing/JTable/7055065/bug7055065.java | 9 b/test/javax/swing/JTable/7068740/bug7068740.java | 13 b/test/javax/swing/JTable/8032874/bug8032874.java | 8 b/test/javax/swing/JTableHeader/6884066/bug6884066.java | 5 b/test/javax/swing/JTableHeader/6889007/bug6889007.java | 7 b/test/javax/swing/JTextArea/4697612/bug4697612.java | 15 b/test/javax/swing/JTextArea/7049024/bug7049024.java | 14 b/test/javax/swing/JTextField/8036819/bug8036819.java | 6 b/test/javax/swing/JToolBar/4247996/bug4247996.java | 6 b/test/javax/swing/JToolBar/4529206/bug4529206.java | 91 + b/test/javax/swing/JToolTip/4644444/bug4644444.html | 44 b/test/javax/swing/JToolTip/4644444/bug4644444.java | 354 ++++ b/test/javax/swing/JToolTip/4846413/bug4846413.java | 6 b/test/javax/swing/JTree/4330357/bug4330357.java | 10 b/test/javax/swing/JTree/4908142/bug4908142.java | 8 b/test/javax/swing/JTree/4927934/bug4927934.java | 20 b/test/javax/swing/JTree/6263446/bug6263446.java | 9 b/test/javax/swing/JTree/6505523/bug6505523.java | 9 b/test/javax/swing/JTree/6578666/bug6578666.java | 80 + b/test/javax/swing/JTree/8003400/Test8003400.java | 15 b/test/javax/swing/JTree/8004298/bug8004298.java | 6 b/test/javax/swing/JViewport/7107099/bug7107099.java | 9 b/test/javax/swing/JWindow/ShapedAndTranslucentWindows/Common.java | 417 +++++ b/test/javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucent.java | 62 b/test/javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucentCanvas.java | 104 + b/test/javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucentGradient.java | 70 b/test/javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucentSwing.java | 95 + b/test/javax/swing/JWindow/ShapedAndTranslucentWindows/SetShapeAndClickSwing.java | 172 ++ b/test/javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedPerPixelTranslucentGradient.java | 77 b/test/javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedTranslucentPerPixelTranslucentGradient.java | 77 b/test/javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentJComboBox.java | 152 + b/test/javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java | 72 b/test/javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentWindowClickSwing.java | 105 + b/test/javax/swing/Popup/6514582/bug6514582.java | 73 b/test/javax/swing/Popup/TaskbarPositionTest.java | 11 b/test/javax/swing/PopupFactory/6276087/NonOpaquePopupMenuTest.java | 6 b/test/javax/swing/RepaintManager/IconifyTest/IconifyTest.java | 7 b/test/javax/swing/Security/6657138/ComponentTest.java | 8 b/test/javax/swing/SwingTest.java | 8 b/test/javax/swing/SwingUtilities/4917669/bug4917669.java | 8 b/test/javax/swing/SwingUtilities/7146377/bug7146377.java | 9 b/test/javax/swing/ToolTipManager/7123767/bug7123767.java | 18 b/test/javax/swing/ToolTipManager/Test6256140.java | 11 b/test/javax/swing/dnd/7171812/bug7171812.java | 5 b/test/javax/swing/plaf/basic/BasicHTML/4251579/bug4251579.java | 5 b/test/javax/swing/plaf/basic/BasicMenuUI/4983388/bug4983388.java | 7 b/test/javax/swing/plaf/basic/BasicTreeUI/8023474/bug8023474.java | 7 b/test/javax/swing/plaf/synth/7158712/bug7158712.java | 4 b/test/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java | 4 b/test/javax/swing/plaf/windows/WindowsRootPaneUI/WrongAltProcessing/WrongAltProcessing.java | 11 b/test/javax/swing/regtesthelpers/Util.java | 24 b/test/javax/swing/reliability/GUIUndFrame.java | 111 + b/test/javax/swing/reliability/GUIZoomFrame.java | 88 + b/test/javax/swing/reliability/Task.java | 50 b/test/javax/swing/reliability/TaskUndJFrameProperties.java | 91 + b/test/javax/swing/reliability/TaskZoomJFrameChangeState.java | 180 ++ b/test/javax/swing/reliability/TaskZoomJFrameRepaint.java | 113 + b/test/javax/swing/text/AbstractDocument/6968363/Test6968363.java | 15 b/test/javax/swing/text/CSSBorder/6796710/bug6796710.java | 5 b/test/javax/swing/text/DefaultEditorKit/4278839/bug4278839.java | 12 b/test/javax/swing/text/JTextComponent/5074573/bug5074573.java | 13 b/test/javax/swing/text/StyledEditorKit/4506788/bug4506788.java | 8 b/test/javax/swing/text/Utilities/bug7045593.java | 5 b/test/javax/swing/text/View/8014863/bug8014863.java | 12 b/test/javax/swing/text/View/8048110/bug8048110.java | 7 b/test/javax/swing/text/html/7189299/bug7189299.java | 7 b/test/javax/swing/text/html/CSS/4530474/bug4530474.java | 6 b/test/javax/swing/text/html/HTMLDocument/8058120/bug8058120.java | 14 b/test/javax/swing/text/html/HTMLEditorKit/4242228/bug4242228.java | 5 b/test/javax/swing/text/html/HTMLEditorKit/5043626/bug5043626.java | 8 b/test/javax/swing/text/html/parser/Parser/7165725/bug7165725.java | 6 b/test/javax/swing/text/html/parser/Test8017492.java | 3 b/test/javax/xml/crypto/dsig/GenerationTests.java | 100 - b/test/jdk/internal/platform/docker/GetFreeSwapSpaceSize.java | 39 b/test/jdk/internal/platform/docker/TestGetFreeSwapSpaceSize.java | 72 b/test/jdk/jfr/jvm/TestDumpOnCrash.java | 13 b/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java | 8 b/test/lib/jdk/test/lib/containers/docker/Common.java | 5 b/test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java | 32 b/test/sun/awt/dnd/8024061/bug8024061.java | 18 959 files changed, 69213 insertions(+), 4263 deletions(-) diffstat for hotspot b/.hgtags | 1 b/THIRD_PARTY_README | 6 b/src/os/linux/vm/osContainer_linux.cpp | 173 +---- b/src/os/linux/vm/osContainer_linux.hpp | 4 b/src/os/linux/vm/os_linux.cpp | 2 b/src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp | 23 b/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp | 16 b/src/share/vm/gc_implementation/g1/g1RemSet.cpp | 16 b/src/share/vm/gc_implementation/g1/heapRegion.cpp | 51 - b/src/share/vm/gc_implementation/g1/heapRegion.hpp | 21 b/src/share/vm/gc_interface/collectedHeap.cpp | 4 b/src/share/vm/gc_interface/collectedHeap.inline.hpp | 20 b/src/share/vm/jfr/recorder/repository/jfrChunkWriter.cpp | 8 b/src/share/vm/jfr/recorder/repository/jfrEmergencyDump.cpp | 299 +++++++++ b/src/share/vm/jfr/recorder/repository/jfrEmergencyDump.hpp | 2 b/src/share/vm/jfr/recorder/repository/jfrRepository.cpp | 318 ---------- b/src/share/vm/memory/genCollectedHeap.cpp | 2 b/src/share/vm/memory/threadLocalAllocBuffer.hpp | 4 b/src/share/vm/oops/oop.hpp | 1 b/src/share/vm/oops/oop.inline.hpp | 12 b/src/share/vm/opto/c2_globals.hpp | 4 b/src/share/vm/runtime/objectMonitor.cpp | 1 b/src/share/vm/runtime/os.cpp | 36 - b/test/compiler/5091921/Test7005594.sh | 4 b/test/compiler/membars/DekkerTest.java | 12 b/test/runtime/containers/docker/DockerBasicTest.java | 5 b/test/testlibrary/com/oracle/java/testlibrary/DockerTestUtils.java | 32 - 27 files changed, 520 insertions(+), 557 deletions(-) Successfully built on x86, x86_64, s390 (Zero), s390x (Zero), ppc (Zero), ppc64, ppc64le, aarch32 (Zero) & aarch64. Ok to push? Thanks, -- Andrew :) 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 shade at redhat.com Thu Jan 7 09:34:35 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 7 Jan 2021 10:34:35 +0100 Subject: [RFR] [8u] 8u282-b04 Upstream Sync In-Reply-To: <20210106200401.GA578088@rincewind> References: <20210106200401.GA578088@rincewind> Message-ID: On 1/6/21 9:04 PM, Andrew Hughes wrote: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b04/corba/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b04/jaxp/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b04/jaxws/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b04/jdk/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b04/hotspot/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b04/langtools/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b04/nashorn/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b04/root/merge.changeset Looks good. > Successfully built on x86, x86_64, s390 (Zero), s390x (Zero), ppc (Zero), > ppc64, ppc64le, aarch32 (Zero) & aarch64. It is a bit weird to see that versions go "back", 0.10k -> 0.10b: -%% This notice is provided with respect to CUP Parser Generator for -Java 0.10k, which may be included with JRE 8, JDK 8, and OpenJDK 8. +%% This notice is provided with respect to CUP Parser Generator for +Java 0.10b, which may be included with JRE 8, JDK 8, and OpenJDK 8. > Ok to push? Yes. -- Thanks, -Aleksey From gnu.andrew at redhat.com Thu Jan 7 17:21:04 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 7 Jan 2021 17:21:04 +0000 Subject: [RFR] [8u] 8u282-b04 Upstream Sync In-Reply-To: References: <20210106200401.GA578088@rincewind> Message-ID: <20210107172104.GA620499@rincewind> On 10:34 Thu 07 Jan , Aleksey Shipilev wrote: > > It is a bit weird to see that versions go "back", 0.10k -> 0.10b: > > -%% This notice is provided with respect to CUP Parser Generator for > -Java 0.10k, which may be included with JRE 8, JDK 8, and OpenJDK 8. > +%% This notice is provided with respect to CUP Parser Generator for > +Java 0.10b, which may be included with JRE 8, JDK 8, and OpenJDK 8. > I noticed this too (not my change, nor do I believe I reviewed this one). It seems it's a mistake in the 8u backport. It should be 11b: https://hg.openjdk.java.net/jdk/jdk/rev/b470da55a673#l2.5 https://www.cs.princeton.edu/~appel/modern/java/CUP/ http://www2.cs.tum.edu/projects/cup/ I've filed a follow-up bug to fix that :/ https://bugs.openjdk.java.net/browse/JDK-8259384 > > Ok to push? > > Yes. > Done. > -- > Thanks, > -Aleksey > Thanks, -- Andrew :) 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 zgu at openjdk.java.net Thu Jan 7 18:45:05 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 7 Jan 2021 18:45:05 GMT Subject: RFR: 8259377: Shenandoah: Enhance weak reference processing timing tacking Message-ID: Please review this enhancement for tracking weak references processing. Test: - [x] hotspot_gc_shenandoah ------------- Commit messages: - cleanup - JDK-8259377: init update Changes: https://git.openjdk.java.net/jdk/pull/1979/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1979&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259377 Stats: 41 lines in 5 files changed: 12 ins; 2 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/1979.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1979/head:pull/1979 PR: https://git.openjdk.java.net/jdk/pull/1979 From zgu at openjdk.java.net Thu Jan 7 19:56:16 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 7 Jan 2021 19:56:16 GMT Subject: RFR: 8259377: Shenandoah: Enhance weak reference processing timing tacking [v2] In-Reply-To: References: Message-ID: > Please review this enhancement for tracking weak references processing. > > Test: > - [x] hotspot_gc_shenandoah Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Fix indentations ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1979/files - new: https://git.openjdk.java.net/jdk/pull/1979/files/a01325d9..baa53fa8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1979&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1979&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1979.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1979/head:pull/1979 PR: https://git.openjdk.java.net/jdk/pull/1979 From iveresov at openjdk.java.net Thu Jan 7 20:36:07 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Thu, 7 Jan 2021 20:36:07 GMT Subject: RFR: 8251462: Remove legacy compilation policy Message-ID: This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! ------------- Commit messages: - Fix copyright years - Remove legacy compilation policy. Changes: https://git.openjdk.java.net/jdk/pull/1985/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251462 Stats: 5285 lines in 95 files changed: 1481 ins; 2979 del; 825 mod Patch: https://git.openjdk.java.net/jdk/pull/1985.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1985/head:pull/1985 PR: https://git.openjdk.java.net/jdk/pull/1985 From jwilhelm at openjdk.java.net Thu Jan 7 20:45:15 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 7 Jan 2021 20:45:15 GMT Subject: RFR: Merge jdk16 Message-ID: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com> Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8249633: doclint reports missing javadoc for JavaFX property methods that have a property description - 8251200: False positive messages about missing comments for serialization - 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days - 8259075: Update the copyright notice in the files generated by CLDR Converter tool - 8259224: (ann) getAnnotatedReceiverType should not parameterize owner(s) of statically nested classes - 8258558: Revert changes for JDK-8252505 and related issues - 8259032: MappedMemorySegmentImpl#makeMappedSegment() ignores Unmapper#pagePosition - 8259007: This test printed a blank page - 8258989: JVM is failed to inline in jdk.internal.vm.vector.VectorSupport::convert - ... and 8 more: https://git.openjdk.java.net/jdk/compare/0e6de4eb...bbd6426f The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=1989&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=1989&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/1989/files Stats: 2957 lines in 68 files changed: 751 ins; 2142 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/1989.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1989/head:pull/1989 PR: https://git.openjdk.java.net/jdk/pull/1989 From cjplummer at openjdk.java.net Thu Jan 7 20:54:01 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 7 Jan 2021 20:54:01 GMT Subject: RFR: 8251462: Remove legacy compilation policy In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 18:43:51 GMT, Igor Veresov wrote: > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. > > Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.java line 35: > 33: * While running the thread, it calls a method (doTask2() ) for number of times (10000). > 34: * That would cause this method to be compiled, which causes a jvmti callback for compiled method load. > 35: * (Hint : to force method compilation -XX:CompileThreshold=900 is used). The test still uses (and the comments state it uses) -XX:CompileThreshold=900 to force compilation, yet it looks like you needed to bump the number of times the method is called from 1000 to 10000 to keep this test working. Why doesn't 1000 still work? ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From jwilhelm at openjdk.java.net Thu Jan 7 21:21:57 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 7 Jan 2021 21:21:57 GMT Subject: Integrated: Merge jdk16 In-Reply-To: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com> References: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com> Message-ID: On Thu, 7 Jan 2021 20:40:49 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: 555641ed Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/555641ed Stats: 2957 lines in 68 files changed: 751 ins; 2142 del; 64 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/1989 From iveresov at openjdk.java.net Thu Jan 7 21:35:11 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Thu, 7 Jan 2021 21:35:11 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 20:50:50 GMT, Chris Plummer wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix s390 build > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.java line 35: > >> 33: * While running the thread, it calls a method (doTask2() ) for number of times (10000). >> 34: * That would cause this method to be compiled, which causes a jvmti callback for compiled method load. >> 35: * (Hint : to force method compilation -XX:CompileThreshold=900 is used). > > The test still uses (and the comments state it uses) -XX:CompileThreshold=900 to force compilation, yet it looks like you needed to bump the number of times the method is called from 1000 to 10000 to keep this test working. Why doesn't 1000 still work? Tiered policy (which the -TieredCompilation emulation mode piggybacks on now) functions by doing periodic callbacks into the runtime to make policy decisions. The callback intervals are a power-of-2. So, because of the resulting rounding I cannot guarantee that the compilation will be triggered exactly at the specified threshold. Plus there are various adaptive mechanisms that I kept on even in the emulation mode that may also result in a method being compiled later than expected. To summarize, in the new world, the advisable way of triggering a compilation is to use the WB API. If that's too much effort, make sure that the method that you'd like to compile is invoked more than 2^(log2(CompileThreshold) + 1) times, plus a bit more. Very few tests actually depend on the legacy behavior, this just happens to be one of those. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Thu Jan 7 21:35:10 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Thu, 7 Jan 2021 21:35:10 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: Message-ID: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. > > Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: Fix s390 build ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1985/files - new: https://git.openjdk.java.net/jdk/pull/1985/files/1a4c6a46..c6983a18 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1985.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1985/head:pull/1985 PR: https://git.openjdk.java.net/jdk/pull/1985 From cjplummer at openjdk.java.net Thu Jan 7 21:51:58 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 7 Jan 2021 21:51:58 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: On Thu, 7 Jan 2021 21:35:10 GMT, Igor Veresov wrote: >> This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> >> I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. >> >> Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Fix s390 build Marking as reviewed, but only for the jvmti tests. I don't believe there are any other svc changes in this PR. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1985 From cjplummer at openjdk.java.net Thu Jan 7 21:51:59 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 7 Jan 2021 21:51:59 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: Message-ID: <1-LylT7vEKyn34M0hmOfrMckVgNK02PaHVy19Mgc_3M=.abfaf6e0-4b16-48d7-a51d-acfe4f87c95c@github.com> On Thu, 7 Jan 2021 21:29:32 GMT, Igor Veresov wrote: >> test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.java line 35: >> >>> 33: * While running the thread, it calls a method (doTask2() ) for number of times (10000). >>> 34: * That would cause this method to be compiled, which causes a jvmti callback for compiled method load. >>> 35: * (Hint : to force method compilation -XX:CompileThreshold=900 is used). >> >> The test still uses (and the comments state it uses) -XX:CompileThreshold=900 to force compilation, yet it looks like you needed to bump the number of times the method is called from 1000 to 10000 to keep this test working. Why doesn't 1000 still work? > > Tiered policy (which the -TieredCompilation emulation mode piggybacks on now) functions by doing periodic callbacks into the runtime to make policy decisions. The callback intervals are a power-of-2. So, because of the resulting rounding I cannot guarantee that the compilation will be triggered exactly at the specified threshold. Plus there are various adaptive mechanisms that I kept on even in the emulation mode that may also result in a method being compiled later than expected. To summarize, in the new world, the advisable way of triggering a compilation is to use the WB API. If that's too much effort, make sure that the method that you'd like to compile is invoked more than 2^(log2(CompileThreshold) + 1) times, plus a bit more. Very few tests actually depend on the legacy behavior, this just happens to be one of those. Ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Thu Jan 7 23:06:19 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Thu, 7 Jan 2021 23:06:19 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. > > Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: Fix another s390 compilation failure ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1985/files - new: https://git.openjdk.java.net/jdk/pull/1985/files/c6983a18..dfffc35b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1985.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1985/head:pull/1985 PR: https://git.openjdk.java.net/jdk/pull/1985 From david.holmes at oracle.com Fri Jan 8 04:57:45 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Jan 2021 14:57:45 +1000 Subject: RFR: 8251462: Remove legacy compilation policy In-Reply-To: References: Message-ID: <01bf1e4c-cda5-32b8-45e4-5b4100314947@oracle.com> Hi Igor, On 8/01/2021 6:36 am, Igor Veresov wrote: > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. Can you clarify, for non-compiler folk, what all the alternative configs actually mean now. I'm a bit confused by this definition: define_pd_global(bool, TieredCompilation, COMPILER1_PRESENT(true) NOT_COMPILER1(false)); as I expected tiered compilation to require COMPILER1 and COMPILER2. Also I see interpreter code that used to be guarded by TieredCompilation now being executed unconditionally, which seems to assume C1 or C2 must be present? Overall it is a big change to digest, but after skimming it looks like a few of the refactorings could have been applied in a layered fashion using multiple commits to make it easier to review. Thanks, David ----- > I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. > > Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! > > ------------- > > Commit messages: > - Fix copyright years > - Remove legacy compilation policy. > > Changes: https://git.openjdk.java.net/jdk/pull/1985/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8251462 > Stats: 5285 lines in 95 files changed: 1481 ins; 2979 del; 825 mod > Patch: https://git.openjdk.java.net/jdk/pull/1985.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/1985/head:pull/1985 > > PR: https://git.openjdk.java.net/jdk/pull/1985 > From iveresov at openjdk.java.net Fri Jan 8 06:09:55 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 8 Jan 2021 06:09:55 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: On Thu, 7 Jan 2021 21:49:56 GMT, Chris Plummer wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix s390 build > > Marking as reviewed, but only for the jvmti tests. I don't believe there are any other svc changes in this PR. Please find the answers in-line. > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ > > Hi Igor, > > On 8/01/2021 6:36 am, Igor Veresov wrote: > > > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > Can you clarify, for non-compiler folk, what all the alternative configs > actually mean now. I'm a bit confused by this definition: > > define_pd_global(bool, TieredCompilation, > COMPILER1_PRESENT(true) NOT_COMPILER1(false)); That's in a c2_globals_*.hpp, which is only included if C2 is present. Given that, if C1 is present as well the flag is set to true. > > as I expected tiered compilation to require COMPILER1 and COMPILER2. > Right. That's exactly what's happening. > Also I see interpreter code that used to be guarded by TieredCompilation > now being executed unconditionally, which seems to assume C1 or C2 must > be present? > Counters and compilation policy callbacks are historically guarded by UseCompiler and UseLoopCounter flags, which are set to false if there are no compilers present. I haven't changed the semantics. > Overall it is a big change to digest, but after skimming it looks like a > few of the refactorings could have been applied in a layered fashion > using multiple commits to make it easier to review. > Frankly, I don't know how to split it into smaller pieces. There are surprisingly lots of interdependencies. However, the best way to think about it is that there are three major parts: 1. CompilerConfig API that is an abstraction over compiler configuration (what's compiled in, what flags are present that restrict compiler usage, etc); 2. The legacy policy removal. 3. Emulation of the old JVM behavior. As far as the runtime part of the change is concerted, it's pretty much only the legacy policy removal. In particular, the parts of the interpreter that dealt with the old policy (basically everything in the interpreter that was under !TieredCompilation has gotten removed). Igor > Thanks, > David > ----- ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 8 06:31:56 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 8 Jan 2021 06:31:56 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: On Fri, 8 Jan 2021 06:07:23 GMT, Igor Veresov wrote: >> Marking as reviewed, but only for the jvmti tests. I don't believe there are any other svc changes in this PR. > > Please find the answers in-line. > >> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ >> >> Hi Igor, >> >> On 8/01/2021 6:36 am, Igor Veresov wrote: >> >> > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> >> Can you clarify, for non-compiler folk, what all the alternative configs >> actually mean now. I'm a bit confused by this definition: >> >> define_pd_global(bool, TieredCompilation, >> COMPILER1_PRESENT(true) NOT_COMPILER1(false)); > > That's in a c2_globals_*.hpp, which is only included if C2 is present. Given that, if C1 is present as well the flag is set to true. >> >> as I expected tiered compilation to require COMPILER1 and COMPILER2. >> > Right. That's exactly what's happening. > >> Also I see interpreter code that used to be guarded by TieredCompilation >> now being executed unconditionally, which seems to assume C1 or C2 must >> be present? >> > > Counters and compilation policy callbacks are historically guarded by UseCompiler and UseLoopCounter flags, which are set to false if there are no compilers present. I haven't changed the semantics. > >> Overall it is a big change to digest, but after skimming it looks like a >> few of the refactorings could have been applied in a layered fashion >> using multiple commits to make it easier to review. >> > > Frankly, I don't know how to split it into smaller pieces. There are surprisingly lots of interdependencies. However, the best way to think about it is that there are three major parts: 1. CompilerConfig API that is an abstraction over compiler configuration (what's compiled in, what flags are present that restrict compiler usage, etc); 2. The legacy policy removal. 3. Emulation of the old JVM behavior. > > As far as the runtime part of the change is concerted, it's pretty much only the legacy policy removal. In particular, the parts of the interpreter that dealt with the old policy (basically everything in the interpreter that was under !TieredCompilation has gotten removed). > > Igor > >> Thanks, >> David >> ----- To clarify the possible configs. 1. There is only one policy now. Functions with both compilers or a single compiler. 2. The best way to control the operation mode is with the ```-XX:CompilationMode=``` flag. Possible values so far are: normal (aka default), high-only (c2 or graal only), quick-only(c1 only), high-only-quick-internal (a special mode for jar graal where only graal itself is compiled by c1, but the user code is compiled with graal). 3. There is a mode that emulates the behavior when the user specifies -TieredCompilation. That's basically the high-only mode. 4. There is also support for legacy policy flags such as CompileThreshold, which would properly setup the policy parameters to match the old behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From david.holmes at oracle.com Mon Jan 11 02:01:42 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Jan 2021 12:01:42 +1000 Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: <67dfcdae-be37-f702-71cf-f58079322824@oracle.com> On 8/01/2021 4:09 pm, Igor Veresov wrote: > On Thu, 7 Jan 2021 21:49:56 GMT, Chris Plummer wrote: > >>> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Fix s390 build >> >> Marking as reviewed, but only for the jvmti tests. I don't believe there are any other svc changes in this PR. > > Please find the answers in-line. > >> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ >> >> Hi Igor, >> >> On 8/01/2021 6:36 am, Igor Veresov wrote: >> >>> This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> >> Can you clarify, for non-compiler folk, what all the alternative configs >> actually mean now. I'm a bit confused by this definition: >> >> define_pd_global(bool, TieredCompilation, >> COMPILER1_PRESENT(true) NOT_COMPILER1(false)); > > That's in a c2_globals_*.hpp, which is only included if C2 is present. Given that, if C1 is present as well the flag is set to true. Sorry I overlooked the exact placement. >> >> as I expected tiered compilation to require COMPILER1 and COMPILER2. >> > Right. That's exactly what's happening. > >> Also I see interpreter code that used to be guarded by TieredCompilation >> now being executed unconditionally, which seems to assume C1 or C2 must >> be present? >> > > Counters and compilation policy callbacks are historically guarded by UseCompiler and UseLoopCounter flags, which are set to false if there are no compilers present. I haven't changed the semantics. That is not at all obvious. For example in templateInterpreterGenerator_aarch64.cpp this code used to guarded by TieredCompilation: 608: __ bind(no_mdo); // Increment counter in MethodCounters const Address invocation_counter(rscratch2, MethodCounters::invocation_counter_offset() + InvocationCounter::counter_offset()); __ get_method_counters(rmethod, rscratch2, done); const Address mask(rscratch2, in_bytes(MethodCounters::invoke_mask_offset())); __ increment_mask_and_jump(invocation_counter, increment, mask, rscratch1, r1, false, Assembler::EQ, overflow); __ bind(done); but now it seems to be executed unconditionally with no reference to either flag you mentioned. > >> Overall it is a big change to digest, but after skimming it looks like a >> few of the refactorings could have been applied in a layered fashion >> using multiple commits to make it easier to review. >> > > Frankly, I don't know how to split it into smaller pieces. There are surprisingly lots of interdependencies. However, the best way to think about it is that there are three major parts: 1. CompilerConfig API that is an abstraction over compiler configuration (what's compiled in, what flags are present that restrict compiler usage, etc); 2. The legacy policy removal. 3. Emulation of the old JVM behavior. I was thinking the ifdef related changes as one commit; then the TieredCompilation removals; then the addition of CompilerConfig API ... These aren't separate changes just different commits within the PR so that it can be reviewed in stages. Cheers, David ----- > As far as the runtime part of the change is concerted, it's pretty much only the legacy policy removal. In particular, the parts of the interpreter that dealt with the old policy (basically everything in the interpreter that was under !TieredCompilation has gotten removed). > > Igor > >> Thanks, >> David >> ----- > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1985 > From github.com+51720475+kdnilsen at openjdk.java.net Mon Jan 11 02:07:45 2021 From: github.com+51720475+kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Mon, 11 Jan 2021 02:07:45 GMT Subject: RFR: Scan remembered Message-ID: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> Add support for scanning remembered set The code has support for two alternative implementations of the remembered set. The current remembered set implementation uses traditional card marking, where the post writer barrier for pointer write operations sets the mark for every overwritten card. A contemplated future remembered set implementation is represented in skeleton form within the shenandoahBufferWithSATBRememberedSet.hpp and shenandoahBufferWithSATBRememberedSet.inline.hpp files. The idea of this alternative remembered set implementation is that the existing SATB buffers will be augmented to additionally remember the address of each overwritten reference field. Subsequent processing of the SATB buffer contents by background GC threads will update the TBD remembered set representation. There are known bugs and performance improvements in the remembered set scanning implementation that have been addressed in certain Amazon-internal commits. These commits will be upstreamed at a later time after other commits not directly related to remembered set scanning are upstreamed. ------------- Commit messages: - Remove printf statements - Remove extraneous white space - Add support for scanning remembered set - Build fixes (JDK assert takes a format string) - Add support for scanning remembered set Changes: https://git.openjdk.java.net/shenandoah/pull/12/files Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=12&range=00 Stats: 1765 lines in 10 files changed: 1755 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/shenandoah/pull/12.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/12/head:pull/12 PR: https://git.openjdk.java.net/shenandoah/pull/12 From iveresov at openjdk.java.net Mon Jan 11 02:56:57 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Mon, 11 Jan 2021 02:56:57 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: On Fri, 8 Jan 2021 06:29:10 GMT, Igor Veresov wrote: >> Please find the answers in-line. >> >>> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ >>> >>> Hi Igor, >>> >>> On 8/01/2021 6:36 am, Igor Veresov wrote: >>> >>> > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >>> >>> Can you clarify, for non-compiler folk, what all the alternative configs >>> actually mean now. I'm a bit confused by this definition: >>> >>> define_pd_global(bool, TieredCompilation, >>> COMPILER1_PRESENT(true) NOT_COMPILER1(false)); >> >> That's in a c2_globals_*.hpp, which is only included if C2 is present. Given that, if C1 is present as well the flag is set to true. >>> >>> as I expected tiered compilation to require COMPILER1 and COMPILER2. >>> >> Right. That's exactly what's happening. >> >>> Also I see interpreter code that used to be guarded by TieredCompilation >>> now being executed unconditionally, which seems to assume C1 or C2 must >>> be present? >>> >> >> Counters and compilation policy callbacks are historically guarded by UseCompiler and UseLoopCounter flags, which are set to false if there are no compilers present. I haven't changed the semantics. >> >>> Overall it is a big change to digest, but after skimming it looks like a >>> few of the refactorings could have been applied in a layered fashion >>> using multiple commits to make it easier to review. >>> >> >> Frankly, I don't know how to split it into smaller pieces. There are surprisingly lots of interdependencies. However, the best way to think about it is that there are three major parts: 1. CompilerConfig API that is an abstraction over compiler configuration (what's compiled in, what flags are present that restrict compiler usage, etc); 2. The legacy policy removal. 3. Emulation of the old JVM behavior. >> >> As far as the runtime part of the change is concerted, it's pretty much only the legacy policy removal. In particular, the parts of the interpreter that dealt with the old policy (basically everything in the interpreter that was under !TieredCompilation has gotten removed). >> >> Igor >> >>> Thanks, >>> David >>> ----- > > To clarify the possible configs. > 1. There is only one policy now. Functions with both compilers or a single compiler. > 2. The best way to control the operation mode is with the ```-XX:CompilationMode=``` flag. Possible values so far are: normal (aka default), high-only (c2 or graal only), quick-only(c1 only), high-only-quick-internal (a special mode for jar graal where only graal itself is compiled by c1, but the user code is compiled with graal). > 3. There is a mode that emulates the behavior when the user specifies -TieredCompilation. That's basically the high-only mode. > 4. There is also support for legacy policy flags such as CompileThreshold, which would properly setup the policy parameters to match the old behavior. Dave, I'm answering inline. > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ > > On 8/01/2021 4:09 pm, Igor Veresov wrote: > > > On Thu, 7 Jan 2021 21:49:56 GMT, Chris Plummer wrote: > > > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > > > Fix s390 build > > > > > > > > > Marking as reviewed, but only for the jvmti tests. I don't believe there are any other svc changes in this PR. > > > > > > Please find the answers in-line. > > > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ > > > Hi Igor, > > > On 8/01/2021 6:36 am, Igor Veresov wrote: > > > > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > > > > > > > > Can you clarify, for non-compiler folk, what all the alternative configs > > > actually mean now. I'm a bit confused by this definition: > > > define_pd_global(bool, TieredCompilation, > > > COMPILER1_PRESENT(true) NOT_COMPILER1(false)); > > > > > > That's in a c2_globals_*.hpp, which is only included if C2 is present. Given that, if C1 is present as well the flag is set to true. > > Sorry I overlooked the exact placement. > > > > as I expected tiered compilation to require COMPILER1 and COMPILER2. > > > > > > Right. That's exactly what's happening. > > > Also I see interpreter code that used to be guarded by TieredCompilation > > > now being executed unconditionally, which seems to assume C1 or C2 must > > > be present? > > > > > > Counters and compilation policy callbacks are historically guarded by UseCompiler and UseLoopCounter flags, which are set to false if there are no compilers present. I haven't changed the semantics. > > That is not at all obvious. For example in > templateInterpreterGenerator_aarch64.cpp this code used to guarded by > TieredCompilation: > > 608: __ bind(no_mdo); > // Increment counter in MethodCounters > const Address invocation_counter(rscratch2, > MethodCounters::invocation_counter_offset() + > InvocationCounter::counter_offset()); > __ get_method_counters(rmethod, rscratch2, done); > const Address mask(rscratch2, > in_bytes(MethodCounters::invoke_mask_offset())); > __ increment_mask_and_jump(invocation_counter, increment, mask, > rscratch1, r1, false, Assembler::EQ, overflow); > __ bind(done); This code is in generate_counter_incr() each call to which is guarded by ```if (inc_counter)```, and ```inc_counter``` is defined as ``` bool inc_counter = UseCompiler || CountCompiledCalls || LogTouchedMethods;```. Again, I haven't changed that at all, that how it always worked. We may try to tidy this up but I feel like this change is big enough already. > > but now it seems to be executed unconditionally with no reference to > either flag you mentioned. > > > > Overall it is a big change to digest, but after skimming it looks like a > > > few of the refactorings could have been applied in a layered fashion > > > using multiple commits to make it easier to review. > > > > > > Frankly, I don't know how to split it into smaller pieces. There are surprisingly lots of interdependencies. However, the best way to think about it is that there are three major parts: 1. CompilerConfig API that is an abstraction over compiler configuration (what's compiled in, what flags are present that restrict compiler usage, etc); 2. The legacy policy removal. 3. Emulation of the old JVM behavior. > > I was thinking the ifdef related changes as one commit; then the > TieredCompilation removals; then the addition of CompilerConfig API ... > > These aren't separate changes just different commits within the PR so > that it can be reviewed in stages. I could've done that, I guess, but I usually like to make my checkpoints compilable. Sorry. > > Cheers, > David > ----- ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From bulasevich at openjdk.java.net Mon Jan 11 09:09:05 2021 From: bulasevich at openjdk.java.net (Boris Ulasevich) Date: Mon, 11 Jan 2021 09:09:05 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: <3FqXOR8NSsGbCExqGxRWPfWOrlb0Rpl0bU3Ug__8I8g=.c74bae33-89af-47b5-b02d-6546a9f538a7@github.com> On Thu, 7 Jan 2021 23:06:19 GMT, Igor Veresov wrote: >> This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> >> I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. >> >> Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Fix another s390 compilation failure src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp line 376: > 374: // Note: In tiered we increment either counters in MethodCounters* or > 375: // in MDO depending if we're profiling or not. > 376: int increment = InvocationCounter::count_increment; The small code below seems not to be equivalent replacement for the above code. I would appreciate some explanation on why we change the things. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From bulasevich at openjdk.java.net Mon Jan 11 09:11:56 2021 From: bulasevich at openjdk.java.net (Boris Ulasevich) Date: Mon, 11 Jan 2021 09:11:56 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: On Mon, 11 Jan 2021 02:54:02 GMT, Igor Veresov wrote: >> To clarify the possible configs. >> 1. There is only one policy now. Functions with both compilers or a single compiler. >> 2. The best way to control the operation mode is with the ```-XX:CompilationMode=``` flag. Possible values so far are: normal (aka default), high-only (c2 or graal only), quick-only(c1 only), high-only-quick-internal (a special mode for jar graal where only graal itself is compiled by c1, but the user code is compiled with graal). >> 3. There is a mode that emulates the behavior when the user specifies -TieredCompilation. That's basically the high-only mode. >> 4. There is also support for legacy policy flags such as CompileThreshold, which would properly setup the policy parameters to match the old behavior. > > Dave, I'm answering inline. > >> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ >> >> On 8/01/2021 4:09 pm, Igor Veresov wrote: >> >> > On Thu, 7 Jan 2021 21:49:56 GMT, Chris Plummer wrote: >> > > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> > > > Fix s390 build >> > > >> > > >> > > Marking as reviewed, but only for the jvmti tests. I don't believe there are any other svc changes in this PR. >> > >> > >> > Please find the answers in-line. >> > > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ >> > > Hi Igor, >> > > On 8/01/2021 6:36 am, Igor Veresov wrote: >> > > > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> > > >> > > >> > > Can you clarify, for non-compiler folk, what all the alternative configs >> > > actually mean now. I'm a bit confused by this definition: >> > > define_pd_global(bool, TieredCompilation, >> > > COMPILER1_PRESENT(true) NOT_COMPILER1(false)); >> > >> > >> > That's in a c2_globals_*.hpp, which is only included if C2 is present. Given that, if C1 is present as well the flag is set to true. >> >> Sorry I overlooked the exact placement. >> >> > > as I expected tiered compilation to require COMPILER1 and COMPILER2. >> > >> > >> > Right. That's exactly what's happening. >> > > Also I see interpreter code that used to be guarded by TieredCompilation >> > > now being executed unconditionally, which seems to assume C1 or C2 must >> > > be present? >> > >> > >> > Counters and compilation policy callbacks are historically guarded by UseCompiler and UseLoopCounter flags, which are set to false if there are no compilers present. I haven't changed the semantics. >> >> That is not at all obvious. For example in >> templateInterpreterGenerator_aarch64.cpp this code used to guarded by >> TieredCompilation: >> >> 608: __ bind(no_mdo); >> // Increment counter in MethodCounters >> const Address invocation_counter(rscratch2, >> MethodCounters::invocation_counter_offset() + >> InvocationCounter::counter_offset()); >> __ get_method_counters(rmethod, rscratch2, done); >> const Address mask(rscratch2, >> in_bytes(MethodCounters::invoke_mask_offset())); >> __ increment_mask_and_jump(invocation_counter, increment, mask, >> rscratch1, r1, false, Assembler::EQ, overflow); >> __ bind(done); > > This code is in generate_counter_incr() each call to which is guarded by ```if (inc_counter)```, and ```inc_counter``` is defined as ``` bool inc_counter = UseCompiler || CountCompiledCalls || LogTouchedMethods;```. Again, I haven't changed that at all, that how it always worked. We may try to tidy this up but I feel like this change is big enough already. > >> >> but now it seems to be executed unconditionally with no reference to >> either flag you mentioned. >> >> > > Overall it is a big change to digest, but after skimming it looks like a >> > > few of the refactorings could have been applied in a layered fashion >> > > using multiple commits to make it easier to review. >> > >> > >> > Frankly, I don't know how to split it into smaller pieces. There are surprisingly lots of interdependencies. However, the best way to think about it is that there are three major parts: 1. CompilerConfig API that is an abstraction over compiler configuration (what's compiled in, what flags are present that restrict compiler usage, etc); 2. The legacy policy removal. 3. Emulation of the old JVM behavior. >> >> I was thinking the ifdef related changes as one commit; then the >> TieredCompilation removals; then the addition of CompilerConfig API ... >> >> These aren't separate changes just different commits within the PR so >> that it can be reviewed in stages. > > I could've done that, I guess, but I usually like to make my checkpoints compilable. Sorry. > >> >> Cheers, >> David >> ----- I see some regression on ARM32 with this change: http://cr.openjdk.java.net/~bulasevich/tmp/8251462_jtreg_hotspot/ ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From rkennke at openjdk.java.net Mon Jan 11 10:58:12 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 11 Jan 2021 10:58:12 GMT Subject: RFR: Scan remembered In-Reply-To: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> Message-ID: On Fri, 8 Jan 2021 17:56:02 GMT, Kelvin Nilsen wrote: > Add support for scanning remembered set > > The code has support for two alternative implementations of the remembered set. The current remembered set implementation uses traditional card marking, where the post writer barrier for pointer write operations sets the mark for every overwritten card. > > A contemplated future remembered set implementation is represented in skeleton form within the shenandoahBufferWithSATBRememberedSet.hpp and shenandoahBufferWithSATBRememberedSet.inline.hpp files. The idea of this alternative remembered set implementation is that the existing SATB buffers will be augmented to additionally remember the address of each overwritten reference field. Subsequent processing of the SATB buffer contents by background GC threads will update the TBD remembered set representation. > > There are known bugs and performance improvements in the remembered set scanning implementation that have been addressed in certain Amazon-internal commits. These commits will be upstreamed at a later time after other commits not directly related to remembered set scanning are upstreamed. Nice work, thanks! I like that it explains so many details in comments. I've found a few issues, see below. src/hotspot/share/gc/shenandoah/shenandoahBufferWithSATBRememberedSet.hpp line 1: > 1: // New file lacks copyright notice. src/hotspot/share/gc/shenandoah/shenandoahBufferWithSATBRememberedSet.hpp line 17: > 15: // a) Just blindly dirty each card that is overwritten with a pointer value, regardless of the written value, as with > 16: // the implementation of traditional direct card marking. When this card's memory region is eventually scanned, the > 17: // the implementation of remembered set scanning will clear the page if it no longer holds references to young-gen Minor: double- 'the' src/hotspot/share/gc/shenandoah/shenandoahBufferWithSATBRememberedSet.hpp line 61: > 59: // existing SATB pre-write barrier to maintain remembered set information rather than using unconditional direct card marking in > 60: // a post-write barrier. > 61: class ShenandoahBufferWithSATBRememberedSet: public CHeapObj { So, if I understand correctly, you intend to piggy-back the field-address onto the SATB queue, is that right? It would mean that we need to double the size of the items in the buffer. And it would also mean that SATB needs to be turned on all the time, not just during marking. Is that correct? If that is so, I wonder if it may be better to do like G1 does and use a separate queue and barrier for this? It looks to me that it is doing exactly what we need here. src/hotspot/share/gc/shenandoah/shenandoahBufferWithSATBRememberedSet.inline.hpp line 1: > 1: Missing copyright header too. src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1159: > 1157: ShenandoahEvacuateUpdateRootsClosure<> cl; > 1158: MarkingCodeBlobClosure blobsCl(&cl, CodeBlobToOopClosure::FixRelocations); > 1159: Extra whitespace src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2730: > 2728: // phase do not need to be scanned by update-refs because the to-space invariant is in force > 2729: // during evacuation and this will assure that any objects residing between > 2730: // r->get_update_watermark() and r->top() hold no pointers to from-space. We do need to scan objects that have been allocated by evacuation, because they may hold from-space refs. For this reason, we bump-up UWM when allocating for evac (in ShFreeSet, iirc). src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2720: > 2718: // an old-gen region as part of an old-gen collection. Otherwise, a subseqent update-refs scan of > 2719: // the same region will see stale pointers and crash. > 2720: // This is probably a bad idea. Unreachable objects are not guaranteed to have their Klass* intact, and may crash when accessed. Why would it crash during subsequent scans? src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2741: > 2739: // allocate from within a free region. > 2740: // > 2741: // Reality is that this code is likely to be replaced with JVM-292 code before we ever get around to What is 'JVM-292' code? ;-) src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 71: > 69: class VMStructs; > 70: > 71: Extra WS src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 40: > 38: #include "gc/shenandoah/shenandoahScanRemembered.hpp" > 39: #include "memory/metaspace.hpp" > 40: #include "gc/shenandoah/shenandoahScanRemembered.hpp" You're including the same header 2x src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 49: > 47: class ShenandoahCollectorPolicy; > 48: class ShenandoahControlThread; > 49: class ShenandoahDirectCardMarkRememberedSet; This looks unused. src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.hpp line 30: > 28: > 29: #include "gc/shared/referenceDiscoverer.hpp" > 30: #include "gc/shared/referencePolicy.hpp" This looks not needed or, if it is actually needed, not related to this change. src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 2: > 1: /* > 2: * Copyright (c) Amazon.com, Inc. or its affiliates. All rights reserved. You do have the copyright header here, good! :-) But it's lacking the year, like so: * Copyright (c) 2021, Amazon.com, Inc. or its affiliates. All rights reserved. src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 2: > 1: /* > 2: * Copyright (c) Amazon.com, Inc. or its affiliates. All rights reserved. Missing copyright year, as above. src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 103: > 101: } > 102: > 103: // Implementation is not correct. ShenandoahBufferWithSATBRememberedSet is a placeholder for future planned improvements. This should go into its own .cpp file I think. Actually, I am not sure that we should add empty&unused code at all. Maybe add it when you also fill the implementation and use? src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 90: > 88: > 89: // The typical parallel remembered set scanning effort consists of the > 90: // following steps, all of which are performed during a JVM safetpoint: Typo: safetpoint -> safepoint. src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 212: > 210: // into ShenandoahRootEvacuator::roots_do() before the invocation of > 211: // _serial_roots.oops_do(oops, worker_id). > 212: This is not quite clear to me. Above you said that all of the work is done during safepoints. Here you mention 'concurrent scanning' ... what is true? src/hotspot/share/gc/shenandoah/shenandoahBufferWithSATBRememberedSet.hpp line 61: > 59: // existing SATB pre-write barrier to maintain remembered set information rather than using unconditional direct card marking in > 60: // a post-write barrier. > 61: class ShenandoahBufferWithSATBRememberedSet: public CHeapObj { It's also lacking the usual #ifndef - #define - #endif sequence that is needed by headers. src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 26: > 24: */ > 25: > 26: // Terminology used within this source file: We usually place big comments like this below #includes and just above class declarations. src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 787: > 785: // What card number corresponds to old-gen heap addresss p. (If p > 786: // does not refer to old-gen memory, the returned value is undefined.) > 787: uint32_t cardNoForAddr(HeapWord *p); Should be named card_no_for_addr(HeapWord* p) to match style of most other Hotspot code. src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp line 2: > 1: /* > 2: * Copyright (c) Amazon.com, Inc. or its affiliates. All rights reserved. Missing copyright year. src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 26: > 24: */ > 25: > 26: Make sure you're adding #include "precompiled.hpp" and make sure it builds with and without --disable-precompiled-headers ------------- Changes requested by rkennke (Reviewer). PR: https://git.openjdk.java.net/shenandoah/pull/12 From rkennke at openjdk.java.net Mon Jan 11 10:58:13 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 11 Jan 2021 10:58:13 GMT Subject: RFR: Scan remembered In-Reply-To: References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> Message-ID: On Mon, 11 Jan 2021 10:13:23 GMT, Roman Kennke wrote: >> Add support for scanning remembered set >> >> The code has support for two alternative implementations of the remembered set. The current remembered set implementation uses traditional card marking, where the post writer barrier for pointer write operations sets the mark for every overwritten card. >> >> A contemplated future remembered set implementation is represented in skeleton form within the shenandoahBufferWithSATBRememberedSet.hpp and shenandoahBufferWithSATBRememberedSet.inline.hpp files. The idea of this alternative remembered set implementation is that the existing SATB buffers will be augmented to additionally remember the address of each overwritten reference field. Subsequent processing of the SATB buffer contents by background GC threads will update the TBD remembered set representation. >> >> There are known bugs and performance improvements in the remembered set scanning implementation that have been addressed in certain Amazon-internal commits. These commits will be upstreamed at a later time after other commits not directly related to remembered set scanning are upstreamed. > > src/hotspot/share/gc/shenandoah/shenandoahBufferWithSATBRememberedSet.inline.hpp line 1: > >> 1: > > Missing copyright header too. And header #ifndef-#define-#endif ;-) ------------- PR: https://git.openjdk.java.net/shenandoah/pull/12 From zgu at openjdk.java.net Mon Jan 11 13:54:08 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 11 Jan 2021 13:54:08 GMT Subject: RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes [v24] In-Reply-To: <4C2MtK5jhW_yHyzDp5k5cAaguy3QlmI0T0LTKf6n978=.8599d416-5d32-40e5-ae7f-9bf5ca5b330d@github.com> References: <4C2MtK5jhW_yHyzDp5k5cAaguy3QlmI0T0LTKf6n978=.8599d416-5d32-40e5-ae7f-9bf5ca5b330d@github.com> Message-ID: On Tue, 5 Jan 2021 13:49:12 GMT, Aleksey Shipilev wrote: >> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: >> >> - Merge >> - Update copyright years >> - Merge >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Concurrent mark does not expect forwarded objects >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Silent valgrind on potential memory leak >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Removed ShenandoahConcurrentMark parameter from concurrent GC entry/op, etc. >> - ... and 21 more: https://git.openjdk.java.net/jdk/compare/a6c08813...b7390c08 > > src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 161: > >> 159: // threads, and performance-wise it doesn't really matter. Adds about 1ms to >> 160: // full-gc. >> 161: { > > This seems to revert JDK-8258490? No. After splitting, full-gc never gets here. > src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 168: > >> 166: while (satb_mq_set.apply_closure_to_completed_buffer(&cl)); >> 167: bool do_nmethods = heap->unload_classes() && !ShenandoahConcurrentRoots::can_do_concurrent_class_unloading(); >> 168: assert(!heap->has_forwarded_objects(), "Not expected"); > > Do you need to move this assert? No, fixed. > src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 335: > >> 333: ShenandoahReferenceProcessor* rp = _heap->ref_processor(); >> 334: task_queues()->reserve(workers->active_workers()); >> 335: ShenandoahMarkConcurrentRootsTask task(task_queues(), rp, ShenandoahPhaseTimings::conc_mark_roots, workers->active_workers()); > > Excess space: `rp, ShenandoahPhaseTimings`. Fixed > src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp line 249: > >> 247: rp->set_soft_reference_policy(true); // forcefully purge all soft references >> 248: >> 249: > > Excess newline? Fixed > src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp line 2: > >> 1: /* >> 2: * Copyright (c) 2019, 2019, Red Hat, Inc. All rights reserved. > > Odd change: 2020 -> 2019. Another merge error. Fixed. > src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp line 96: > >> 94: TASKQUEUE_STATS_ONLY(task_queues()->print_taskqueue_stats()); >> 95: TASKQUEUE_STATS_ONLY(task_queues()->reset_taskqueue_stats()); >> 96: > > Excess newline Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/1009 From tschatzl at openjdk.java.net Mon Jan 11 16:38:56 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 11 Jan 2021 16:38:56 GMT Subject: RFR: 8258254: Move PtrQueue flush to PtrQueueSet subclasses In-Reply-To: <-QQP60eAp1I0kSia-QngOIk1qZ09fGriqo2A2866xv4=.60d6cb4d-1a13-4443-8cb6-389568113c9c@github.com> References: <-QQP60eAp1I0kSia-QngOIk1qZ09fGriqo2A2866xv4=.60d6cb4d-1a13-4443-8cb6-389568113c9c@github.com> Message-ID: On Sun, 20 Dec 2020 10:03:15 GMT, Kim Barrett wrote: > Please review this change to the PtrQueue hierarchy, changing queue flushing > from an intrinsic operation of the queue to an operation the qset performs on > a queue. This is a piece of the refactoring being done under JDK-8258251, > separated out for easier review. > > This change also removes a couple of no longer used internal helper functions > from PtrQueue. > > Testing: > mach5 tier1 > local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1851 From shade at openjdk.java.net Mon Jan 11 16:53:56 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Jan 2021 16:53:56 GMT Subject: RFR: 8258254: Move PtrQueue flush to PtrQueueSet subclasses In-Reply-To: <-QQP60eAp1I0kSia-QngOIk1qZ09fGriqo2A2866xv4=.60d6cb4d-1a13-4443-8cb6-389568113c9c@github.com> References: <-QQP60eAp1I0kSia-QngOIk1qZ09fGriqo2A2866xv4=.60d6cb4d-1a13-4443-8cb6-389568113c9c@github.com> Message-ID: On Sun, 20 Dec 2020 10:03:15 GMT, Kim Barrett wrote: > Please review this change to the PtrQueue hierarchy, changing queue flushing > from an intrinsic operation of the queue to an operation the qset performs on > a queue. This is a piece of the refactoring being done under JDK-8258251, > separated out for easier review. > > This change also removes a couple of no longer used internal helper functions > from PtrQueue. > > Testing: > mach5 tier1 > local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC Shenandoah and shared parts look fine. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1851 From shade at openjdk.java.net Mon Jan 11 17:45:02 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Jan 2021 17:45:02 GMT Subject: RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes [v27] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 20:36:08 GMT, Zhengyu Gu wrote: >> This is the first part of refactoring, that aims to isolate three Shenandoah GC modes (concurrent, degenerated and full gc). >> >> Shenandoah started with two GC modes, concurrent and full gc, with minimal shared code, mainly in mark phase. After introducing degenerated GC, it shared quite large portion of code with concurrent GC, with the concept that degenerated GC can simply pick up remaining work of concurrent GC in STW mode. >> >> It was not a big problem at that time, since concurrent GC also processed roots STW. Since Shenandoah gradually moved root processing into concurrent phase, code started to diverge, that made code hard to reason and maintain. >> >> First step, I would like to split STW and concurrent mark, so that: >> 1) Code has to special case for STW and concurrent mark. >> 2) STW mark does not need to rendezvous workers between root mark and the rest of mark >> 3) STW mark does not need to activate SATB barrier and drain SATB buffers. >> 4) STW mark does not need to remark some of roots. >> >> The patch mainly just shuffles code. Creates a base class ShenandoahMark, and moved shared code (from current shenandoahConcurrentMark) into this base class. I did 'git mv shenandoahConcurrentMark.inline.hpp shenandoahMark.inline.hpp, but git does not seem to reflect that. >> >> A few changes: >> 1) Moved task queue set from ShenandoahConcurrentMark to ShenandoahHeap. ShenandoahMark and its subclasses are stateless. Instead, mark states are maintained in task queue, mark bitmap and SATB buffers, so that they can be created on demand. >> 2) Split ShenandoahConcurrentRootScanner template to ShenandoahConcurrentRootScanner and ShenandoahSTWRootScanner >> 3) Split code inside op_final_mark code into finish_mark and prepare_evacuation helper functions. >> 4) Made ShenandoahMarkCompact stack allocated (as well as ShenandoahConcurrentGC and ShenandoahDegeneratedGC in upcoming refactoring) > > Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: > > - Merge branch 'master' into JDK-8255019-sh-mark > - Silent MacOSX build > - @shade's comments > - Merge > - Update copyright years > - Merge > - Merge branch 'master' into JDK-8255019-sh-mark > - Concurrent mark does not expect forwarded objects > - Merge branch 'master' into JDK-8255019-sh-mark > - Merge branch 'master' into JDK-8255019-sh-mark > - ... and 24 more: https://git.openjdk.java.net/jdk/compare/4d3d5991...a6540b99 Changes requested by shade (Reviewer). src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 251: > 249: } > 250: > 251: _marking_context = new ShenandoahMarkingContext(_heap_region, _bitmap_region, _num_regions, MAX2(_max_workers, 1U)); So, `MAX2` protects from `_max_workers == 0`? Is that even plausible? If not, it should be an assert inside `ShenandoahMarkingContext` constructor? src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1610: > 1608: // Make above changes visible to worker threads > 1609: OrderAccess::fence(); > 1610: ShenandoahConcurrentMark mark; Add (or rather, retain), a newline before this statement. src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2212: > 2210: if (point == _degenerated_mark) { > 2211: finish_mark(); > 2212: } So if we don't call `finish_mark`, do we ever call `set_concurrent_mark_in_progress(false);` and `mark_complete_marking_context();`? ------------- PR: https://git.openjdk.java.net/jdk/pull/1009 From shade at openjdk.java.net Mon Jan 11 17:45:04 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Jan 2021 17:45:04 GMT Subject: RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes [v24] In-Reply-To: References: <4C2MtK5jhW_yHyzDp5k5cAaguy3QlmI0T0LTKf6n978=.8599d416-5d32-40e5-ae7f-9bf5ca5b330d@github.com> Message-ID: On Mon, 11 Jan 2021 13:49:16 GMT, Zhengyu Gu wrote: >> src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 161: >> >>> 159: // threads, and performance-wise it doesn't really matter. Adds about 1ms to >>> 160: // full-gc. >>> 161: { >> >> This seems to revert JDK-8258490? > > No. After splitting, full-gc never gets here. Why the comment that mentions mark-compact and full-gc then? >> src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 168: >> >>> 166: while (satb_mq_set.apply_closure_to_completed_buffer(&cl)); >>> 167: bool do_nmethods = heap->unload_classes() && !ShenandoahConcurrentRoots::can_do_concurrent_class_unloading(); >>> 168: assert(!heap->has_forwarded_objects(), "Not expected"); >> >> Do you need to move this assert? > > No, fixed. Note it still removes the new line. ------------- PR: https://git.openjdk.java.net/jdk/pull/1009 From shade at openjdk.java.net Mon Jan 11 17:45:05 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Jan 2021 17:45:05 GMT Subject: RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes [v24] In-Reply-To: <4C2MtK5jhW_yHyzDp5k5cAaguy3QlmI0T0LTKf6n978=.8599d416-5d32-40e5-ae7f-9bf5ca5b330d@github.com> References: <4C2MtK5jhW_yHyzDp5k5cAaguy3QlmI0T0LTKf6n978=.8599d416-5d32-40e5-ae7f-9bf5ca5b330d@github.com> Message-ID: On Tue, 5 Jan 2021 13:55:17 GMT, Aleksey Shipilev wrote: >> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: >> >> - Merge >> - Update copyright years >> - Merge >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Concurrent mark does not expect forwarded objects >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Silent valgrind on potential memory leak >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Removed ShenandoahConcurrentMark parameter from concurrent GC entry/op, etc. >> - ... and 21 more: https://git.openjdk.java.net/jdk/compare/a6c08813...b7390c08 > > src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp line 58: > >> 56: // TODO: where to put them >> 57: static void update_roots(ShenandoahPhaseTimings::Phase root_phase); >> 58: static void update_thread_roots(ShenandoahPhaseTimings::Phase root_phase); > > Sounds like these better to be shared in `ShenandoahMark`? This is still unanswered. ------------- PR: https://git.openjdk.java.net/jdk/pull/1009 From kdnilsen at amazon.com Mon Jan 11 17:48:26 2021 From: kdnilsen at amazon.com (Nilsen, Kelvin) Date: Mon, 11 Jan 2021 17:48:26 +0000 Subject: RFR: Scan remembered In-Reply-To: References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> Message-ID: <9471221F-115C-4132-9661-D996BC6DF13E@amazon.com> Thank you for the quick and detailed response. I will work on addressing the various issues you've raised. Below, I embed a response to one of your questions. ?On 1/11/21, 2:59 AM, "shenandoah-dev on behalf of Roman Kennke" wrote: > So, if I understand correctly, you intend to piggy-back the field-address onto the SATB queue, is that right? > It would mean that we need to double the size of the items in the buffer. And it would also mean that SATB > to be turned on all the time, not just during marking. Is that correct? If that is so, I wonder if it may be better > to do like G1 does and use a separate queue and barrier for this? It looks to me that it is doing exactly what > we need here. Here are a few aspects of the current design, some of which might change as we gather feedback from initial implementation efforts: 1. The thought was to use one bit within each pointer pushed into the SATB buffer to distinguish between the traditional SATB contents (reference values overwritten) and the new reference values (addresses of fields overwritten). Alternatively, we might push traditional SATB values to the start of the SATB buffer and push overwritten addresses to the end of the SATB buffer. 2. The traditional SATB write barrier is only enabled while either young-gen or old-gen (or both) concurrent marking is active. 3. A lighter weight pre-write barrier is active at other times. This lighter weight barrier does not need to pre-fetch value overwritten before performing the write so the cost of this form of the barrier is much lower than the cost of the traditional SATB pre-write barrier. 4. We have prototyped an implementation of the "enhanced pre-write barrier" for which the code is roughly. We have not yet implemented the C1 and C2 versions of this barrier: if (SATB buffer has fewer than 2 available slots) take-the-slow-path(); else { push_to_satb_as_address (address overwritten into SATB buffer); if (SATB is enabled) { satb_value = fetch overwritten value(); push_to_satb_as_overwritten_value (satb_value); } } 5. We have looked at (but not fully digested) the G1 separate queue and write barrier. Indeed, it is very similar to what we need and ultimately, we may borrow from and/or reuse that implementation. However, we are also thinking that it might be more efficient to piggy-back on the existing SATB infrastructure in that this approach requires fewer dedicated registers (and/or less access to dedicated thread-local fields), fewer checks along common paths (check one buffer overflow instead of two), and smaller in-lined code for fast paths. We have one pointer to the SATB buffer, and one count (or index) of how much room remains within the SATB buffer. Given that old-gen and young-gen marking may happen concurrently, and that a single old-gen concurrent mark may span the time required for multiple complete young-gen GC cycles, we anticipate that the genshen SATB write barrier is likely to be enabled for a higher overall percentage of total execution time than is typical with traditional Shenandoah. This remains to be measured on aggressively scheduled workloads. (A genshen design objective is so support higher utilization of memory with same a given allocation rate, and without pauses. This probably means GC concurrent marking is active a larger percentage of time.) 6. We realize this increases the amount of data traffic funneled through the SATB buffer, so we are anticipating that we would want to increase the size of each SATB buffer. We welcome additional thoughts and recommendations. From iveresov at openjdk.java.net Mon Jan 11 17:52:02 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Mon, 11 Jan 2021 17:52:02 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: <3FqXOR8NSsGbCExqGxRWPfWOrlb0Rpl0bU3Ug__8I8g=.c74bae33-89af-47b5-b02d-6546a9f538a7@github.com> References: <3FqXOR8NSsGbCExqGxRWPfWOrlb0Rpl0bU3Ug__8I8g=.c74bae33-89af-47b5-b02d-6546a9f538a7@github.com> Message-ID: On Mon, 11 Jan 2021 09:06:36 GMT, Boris Ulasevich wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix another s390 compilation failure > > src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp line 376: > >> 374: // Note: In tiered we increment either counters in MethodCounters* or >> 375: // in MDO depending if we're profiling or not. >> 376: int increment = InvocationCounter::count_increment; > > The small code below seems not to be equivalent replacement for the above code. I would appreciate some explanation on why we change the things. Thanks. It's a just the code that was guarded before by ```if (TieredCompilation)```. It was just the else part that's gotten removed. Since the new policy is base off of tiered we don't need the old style of callbacks. Is there something else that you've noticed? ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Mon Jan 11 17:56:54 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Mon, 11 Jan 2021 17:56:54 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: On Mon, 11 Jan 2021 09:09:12 GMT, Boris Ulasevich wrote: > I see some regression on ARM32 with this change: > http://cr.openjdk.java.net/~bulasevich/tmp/8251462_jtreg_hotspot/ I don't think those are related to the changes. Those are probably some preexisting c1 and c2 problems respectively that for some reason weren't triggered before. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From zgu at openjdk.java.net Mon Jan 11 18:26:04 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 11 Jan 2021 18:26:04 GMT Subject: RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes [v27] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 16:42:30 GMT, Aleksey Shipilev wrote: >> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: >> >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Silent MacOSX build >> - @shade's comments >> - Merge >> - Update copyright years >> - Merge >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Concurrent mark does not expect forwarded objects >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Merge branch 'master' into JDK-8255019-sh-mark >> - ... and 24 more: https://git.openjdk.java.net/jdk/compare/4d3d5991...a6540b99 > > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1610: > >> 1608: // Make above changes visible to worker threads >> 1609: OrderAccess::fence(); >> 1610: ShenandoahConcurrentMark mark; > > Add (or rather, retain), a newline before this statement. Fixed > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 251: > >> 249: } >> 250: >> 251: _marking_context = new ShenandoahMarkingContext(_heap_region, _bitmap_region, _num_regions, MAX2(_max_workers, 1U)); > > So, `MAX2` protects from `_max_workers == 0`? Is that even plausible? If not, it should be an assert inside `ShenandoahMarkingContext` constructor? Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/1009 From zgu at openjdk.java.net Mon Jan 11 18:41:06 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 11 Jan 2021 18:41:06 GMT Subject: RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes [v24] In-Reply-To: References: <4C2MtK5jhW_yHyzDp5k5cAaguy3QlmI0T0LTKf6n978=.8599d416-5d32-40e5-ae7f-9bf5ca5b330d@github.com> Message-ID: On Mon, 11 Jan 2021 17:42:02 GMT, Aleksey Shipilev wrote: >> src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp line 58: >> >>> 56: // TODO: where to put them >>> 57: static void update_roots(ShenandoahPhaseTimings::Phase root_phase); >>> 58: static void update_thread_roots(ShenandoahPhaseTimings::Phase root_phase); >> >> Sounds like these better to be shared in `ShenandoahMark`? > > This is still unanswered. They are not really marking functions, they do not belong to there neither ... I left them there, and moved them to ShenandoahGC in next PR (isolate GCs). Okay? ------------- PR: https://git.openjdk.java.net/jdk/pull/1009 From zgu at openjdk.java.net Mon Jan 11 18:41:09 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 11 Jan 2021 18:41:09 GMT Subject: RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes [v24] In-Reply-To: <4C2MtK5jhW_yHyzDp5k5cAaguy3QlmI0T0LTKf6n978=.8599d416-5d32-40e5-ae7f-9bf5ca5b330d@github.com> References: <4C2MtK5jhW_yHyzDp5k5cAaguy3QlmI0T0LTKf6n978=.8599d416-5d32-40e5-ae7f-9bf5ca5b330d@github.com> Message-ID: On Tue, 5 Jan 2021 13:59:35 GMT, Aleksey Shipilev wrote: >> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: >> >> - Merge >> - Update copyright years >> - Merge >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Concurrent mark does not expect forwarded objects >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Silent valgrind on potential memory leak >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Removed ShenandoahConcurrentMark parameter from concurrent GC entry/op, etc. >> - ... and 21 more: https://git.openjdk.java.net/jdk/compare/a6c08813...b7390c08 > > src/hotspot/share/gc/shenandoah/shenandoahMark.cpp line 38: > >> 36: #include "gc/shenandoah/shenandoahUtils.hpp" >> 37: #include "gc/shenandoah/shenandoahVerifier.hpp" >> 38: > > Excess newline? Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/1009 From zgu at openjdk.java.net Mon Jan 11 18:58:17 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 11 Jan 2021 18:58:17 GMT Subject: RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes [v28] In-Reply-To: References: Message-ID: <5ly9_tDk3Ja-pmAdkYU4BjREIHtqsJB2NhkSnIQFbI8=.63aeec1e-2e79-42f5-baeb-055e8740029b@github.com> > This is the first part of refactoring, that aims to isolate three Shenandoah GC modes (concurrent, degenerated and full gc). > > Shenandoah started with two GC modes, concurrent and full gc, with minimal shared code, mainly in mark phase. After introducing degenerated GC, it shared quite large portion of code with concurrent GC, with the concept that degenerated GC can simply pick up remaining work of concurrent GC in STW mode. > > It was not a big problem at that time, since concurrent GC also processed roots STW. Since Shenandoah gradually moved root processing into concurrent phase, code started to diverge, that made code hard to reason and maintain. > > First step, I would like to split STW and concurrent mark, so that: > 1) Code has to special case for STW and concurrent mark. > 2) STW mark does not need to rendezvous workers between root mark and the rest of mark > 3) STW mark does not need to activate SATB barrier and drain SATB buffers. > 4) STW mark does not need to remark some of roots. > > The patch mainly just shuffles code. Creates a base class ShenandoahMark, and moved shared code (from current shenandoahConcurrentMark) into this base class. I did 'git mv shenandoahConcurrentMark.inline.hpp shenandoahMark.inline.hpp, but git does not seem to reflect that. > > A few changes: > 1) Moved task queue set from ShenandoahConcurrentMark to ShenandoahHeap. ShenandoahMark and its subclasses are stateless. Instead, mark states are maintained in task queue, mark bitmap and SATB buffers, so that they can be created on demand. > 2) Split ShenandoahConcurrentRootScanner template to ShenandoahConcurrentRootScanner and ShenandoahSTWRootScanner > 3) Split code inside op_final_mark code into finish_mark and prepare_evacuation helper functions. > 4) Made ShenandoahMarkCompact stack allocated (as well as ShenandoahConcurrentGC and ShenandoahDegeneratedGC in upcoming refactoring) Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Fixes based on shade's comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1009/files - new: https://git.openjdk.java.net/jdk/pull/1009/files/a6540b99..37cda8b7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1009&range=27 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1009&range=26-27 Stats: 10 lines in 4 files changed: 3 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1009.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1009/head:pull/1009 PR: https://git.openjdk.java.net/jdk/pull/1009 From shade at openjdk.java.net Mon Jan 11 19:08:03 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Jan 2021 19:08:03 GMT Subject: RFR: 8259580: Shenandoah: uninitialized label in VerifyThreadGCState Message-ID: "label" is passed, but never hooked into the field. So instead of reporting a GC bug, Verifier would probably crash itself trying to read garbage memory. ------------- Commit messages: - 8259580: Shenandoah: uninitialized label in VerifyThreadGCState Changes: https://git.openjdk.java.net/jdk/pull/2033/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2033&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259580 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2033.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2033/head:pull/2033 PR: https://git.openjdk.java.net/jdk/pull/2033 From zgu at openjdk.java.net Mon Jan 11 19:34:57 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 11 Jan 2021 19:34:57 GMT Subject: RFR: 8259580: Shenandoah: uninitialized label in VerifyThreadGCState In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 19:02:55 GMT, Aleksey Shipilev wrote: > "label" is passed, but never hooked into the field. So instead of reporting a GC bug, Verifier would probably crash itself trying to read garbage memory. Looks good ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2033 From rkennke at openjdk.java.net Mon Jan 11 20:57:06 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 11 Jan 2021 20:57:06 GMT Subject: RFR: 8259580: Shenandoah: uninitialized label in VerifyThreadGCState In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 19:02:55 GMT, Aleksey Shipilev wrote: > "label" is passed, but never hooked into the field. So instead of reporting a GC bug, Verifier would probably crash itself trying to read garbage memory. src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 606: > 604: private: > 605: const char* const _label; > 606: char const _expected; Why can't _expected not be const char* const too? Are we really messing with the string on the way? ------------- PR: https://git.openjdk.java.net/jdk/pull/2033 From kbarrett at openjdk.java.net Tue Jan 12 03:15:02 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 12 Jan 2021 03:15:02 GMT Subject: RFR: 8258254: Move PtrQueue flush to PtrQueueSet subclasses In-Reply-To: References: <-QQP60eAp1I0kSia-QngOIk1qZ09fGriqo2A2866xv4=.60d6cb4d-1a13-4443-8cb6-389568113c9c@github.com> Message-ID: <90ADrhvR1wYnK9Kk3aYW7oseegRFEM_Mnb1WqBQNUFg=.8525b43e-99d0-4136-8bed-6255294188cc@github.com> On Mon, 11 Jan 2021 16:51:05 GMT, Aleksey Shipilev wrote: >> Please review this change to the PtrQueue hierarchy, changing queue flushing >> from an intrinsic operation of the queue to an operation the qset performs on >> a queue. This is a piece of the refactoring being done under JDK-8258251, >> separated out for easier review. >> >> This change also removes a couple of no longer used internal helper functions >> from PtrQueue. >> >> Testing: >> mach5 tier1 >> local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC > > Shenandoah and shared parts look fine. Thanks @shipilev and @tschatzl for reviewing. ------------- PR: https://git.openjdk.java.net/jdk/pull/1851 From kbarrett at openjdk.java.net Tue Jan 12 04:15:20 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 12 Jan 2021 04:15:20 GMT Subject: RFR: 8258254: Move PtrQueue flush to PtrQueueSet subclasses [v2] In-Reply-To: <-QQP60eAp1I0kSia-QngOIk1qZ09fGriqo2A2866xv4=.60d6cb4d-1a13-4443-8cb6-389568113c9c@github.com> References: <-QQP60eAp1I0kSia-QngOIk1qZ09fGriqo2A2866xv4=.60d6cb4d-1a13-4443-8cb6-389568113c9c@github.com> Message-ID: > Please review this change to the PtrQueue hierarchy, changing queue flushing > from an intrinsic operation of the queue to an operation the qset performs on > a queue. This is a piece of the refactoring being done under JDK-8258251, > separated out for easier review. > > This change also removes a couple of no longer used internal helper functions > from PtrQueue. > > Testing: > mach5 tier1 > local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into move_flush - update copyrights - move flush ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1851/files - new: https://git.openjdk.java.net/jdk/pull/1851/files/9b51552f..07d17089 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1851&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1851&range=00-01 Stats: 38704 lines in 1385 files changed: 14517 ins; 11573 del; 12614 mod Patch: https://git.openjdk.java.net/jdk/pull/1851.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1851/head:pull/1851 PR: https://git.openjdk.java.net/jdk/pull/1851 From kbarrett at openjdk.java.net Tue Jan 12 04:15:21 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 12 Jan 2021 04:15:21 GMT Subject: Integrated: 8258254: Move PtrQueue flush to PtrQueueSet subclasses In-Reply-To: <-QQP60eAp1I0kSia-QngOIk1qZ09fGriqo2A2866xv4=.60d6cb4d-1a13-4443-8cb6-389568113c9c@github.com> References: <-QQP60eAp1I0kSia-QngOIk1qZ09fGriqo2A2866xv4=.60d6cb4d-1a13-4443-8cb6-389568113c9c@github.com> Message-ID: On Sun, 20 Dec 2020 10:03:15 GMT, Kim Barrett wrote: > Please review this change to the PtrQueue hierarchy, changing queue flushing > from an intrinsic operation of the queue to an operation the qset performs on > a queue. This is a piece of the refactoring being done under JDK-8258251, > separated out for easier review. > > This change also removes a couple of no longer used internal helper functions > from PtrQueue. > > Testing: > mach5 tier1 > local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC This pull request has now been integrated. Changeset: 77f62909 Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/77f62909 Stats: 147 lines in 12 files changed: 55 ins; 69 del; 23 mod 8258254: Move PtrQueue flush to PtrQueueSet subclasses Reviewed-by: tschatzl, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/1851 From iveresov at openjdk.java.net Tue Jan 12 05:04:11 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Tue, 12 Jan 2021 05:04:11 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. > > Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: Check legacy flags validity before deriving flag values for emulation mode. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1985/files - new: https://git.openjdk.java.net/jdk/pull/1985/files/dfffc35b..82dffbe9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=02-03 Stats: 49 lines in 2 files changed: 37 ins; 8 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1985.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1985/head:pull/1985 PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Tue Jan 12 05:07:01 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Tue, 12 Jan 2021 05:07:01 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: <_kzqYF9JIc1ten32g062993eEyhRKHBGOoKoeemvQ9w=.c98f3d6c-cea1-4a8b-b64e-b4e7108d643d@github.com> On Mon, 11 Jan 2021 17:54:10 GMT, Igor Veresov wrote: >> I see some regression on ARM32 with this change: >> http://cr.openjdk.java.net/~bulasevich/tmp/8251462_jtreg_hotspot/ > >> I see some regression on ARM32 with this change: >> http://cr.openjdk.java.net/~bulasevich/tmp/8251462_jtreg_hotspot/ > > I don't think those are related to the changes. Those are probably some preexisting c1 and c2 problems respectively that for some reason weren't triggered before. > > The TestOptionsWithRanges is my fault though. I'll fix that. I've added the flag validity pre-checks, which should solve the issues with VM complaining about tiered flags being invalid as a result of CompileThreshold and friends being invalid. We'd have to solve the C1 SIGILL and the C2 loop opts crash separately. Those are not really related to the change. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From stefank at openjdk.java.net Tue Jan 12 10:12:59 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 12 Jan 2021 10:12:59 GMT Subject: RFR: 8256814: WeakProcessorPhases may be redundant In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 04:59:28 GMT, Kim Barrett wrote: > Please review this change which eliminates the WeakProcessorPhase class. > > The OopStorageSet class is changed to provide scoped enums for the different > categories: StrongId, WeakId, and Id (for the union of strong and weak). > An accessor is provided for obtaining the storage corresponding to a > category value. > > Various other enumerator ranges, array sizes and indices, and iterations are > derived directly from the corresponding OopStorageSet category's enum range. > > Iteration over a category of enumerators can be done via EnumIterator. The > iteration over storage objects makes use of that enum iteration, rather than > having a bespoke implementation. Some use-cases need iteration of the > enumerators, with storage lookup from the enumerator; other use-cases just > need the storage objects. > > Testing: > mach5 tier1-6 > Local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC I think this looks good. I have a few comments that I would like to get addressed, but they are not blockers if you want to proceed with what you have. src/hotspot/share/gc/shared/oopStorageSetParState.hpp line 35: > 33: > 34: // Base class for OopStorageSet{Strong,Weak}ParState. > 35: template While reviewing this, it was not immediately obvious what T represent. EnumRange uses the name StorageId, maybe use the same here? src/hotspot/share/gc/shared/oopStorageSetParState.hpp line 52: > 50: > 51: NONCOPYABLE(OopStorageSetParState); > 52: }; We tend to put the member variables at the top of classes. I don't think ParState needs to be public, and this could be changed to: template class OopStorageSetParState { using ParState = OopStorage::ParState; ValueObjArray().size()> _par_states; public: ParState* par_state(T id) const { return _par_states.at(checked_cast(EnumRange().index(id))); } protected: OopStorageSetParState() : _par_states(OopStorageSet::Range().begin()) {} ~OopStorageSetParState() = default; private: NONCOPYABLE(OopStorageSetParState); }; src/hotspot/share/gc/shared/oopStorageSetParState.hpp line 58: > 56: class OopStorageSetStrongParState > 57: : public OopStorageSetParState > 58: { We usually keep the `{` on the same line. src/hotspot/share/gc/shared/oopStorageSetParState.hpp line 68: > 66: class OopStorageSetWeakParState > 67: : public OopStorageSetParState > 68: { Same comment as above. src/hotspot/share/gc/shared/oopStorageSetParState.inline.hpp line 36: > 34: > 35: template > 36: template Other places in the file uses `template <` so the usage of `template<` makes the code inconsistent. src/hotspot/share/gc/shared/weakProcessorTimes.hpp line 37: > 35: class WeakProcessorTimes { > 36: public: > 37: using StorageId = OopStorageSet::WeakId; Could be private. test/hotspot/gtest/gc/shared/test_oopStorageSet.cpp line 48: > 46: > 47: template > 48: static void check_iterator(OopStorageSet::Iterator it, All the functions you changed are named `_iterator` and tested OopStorageSet::Iterator. Now the name is the same, but instead they test the Range facility. I think these functions should be renamed. Alternatively, we keep the tests for the OopStorageSet::Iterator and create a new set for the Range? ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1862 From shade at openjdk.java.net Tue Jan 12 10:55:03 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 12 Jan 2021 10:55:03 GMT Subject: RFR: 8259580: Shenandoah: uninitialized label in VerifyThreadGCState In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 20:54:28 GMT, Roman Kennke wrote: >> "label" is passed, but never hooked into the field. So instead of reporting a GC bug, Verifier would probably crash itself trying to read garbage memory. > > src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 606: > >> 604: private: >> 605: const char* const _label; >> 606: char const _expected; > > Why can't _expected not be const char* const too? Are we really messing with the string on the way? `_expected` is not `const char*`, it is `const char`, where `const` is placed near the field identifier for consistency. ------------- PR: https://git.openjdk.java.net/jdk/pull/2033 From bulasevich at openjdk.java.net Tue Jan 12 14:44:01 2021 From: bulasevich at openjdk.java.net (Boris Ulasevich) Date: Tue, 12 Jan 2021 14:44:01 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: <_kzqYF9JIc1ten32g062993eEyhRKHBGOoKoeemvQ9w=.c98f3d6c-cea1-4a8b-b64e-b4e7108d643d@github.com> References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> <_kzqYF9JIc1ten32g062993eEyhRKHBGOoKoeemvQ9w=.c98f3d6c-cea1-4a8b-b64e-b4e7108d643d@github.com> Message-ID: On Tue, 12 Jan 2021 05:03:45 GMT, Igor Veresov wrote: >>> I see some regression on ARM32 with this change: >>> http://cr.openjdk.java.net/~bulasevich/tmp/8251462_jtreg_hotspot/ >> >> I don't think those are related to the changes. Those are probably some preexisting c1 and c2 problems respectively that for some reason weren't triggered before. >> >> The TestOptionsWithRanges is my fault though. I'll fix that. > > I've added the flag validity pre-checks, which should solve the issues with VM complaining about tiered flags being invalid as a result of CompileThreshold and friends being invalid. We'd have to solve the C1 SIGILL and the C2 loop opts crash separately. Those are not really related to the change. Ok. I will see what is wrong there. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kornelpal at gmail.com Tue Jan 12 23:06:45 2021 From: kornelpal at gmail.com (Kornel Pal) Date: Wed, 13 Jan 2021 00:06:45 +0100 Subject: SoftMaxHeapSize has no effect with Cassandra In-Reply-To: References: Message-ID: Hi, Thank you for getting back to me and for filing a bug. Aleksey Shipilev wrote: > Please post the full list of GC flags you are using? And maybe the excerpts from the GC logs that show unexpected (with ShenandoahSoftMaxHeapSize setting) and expected (with ShenandoahMinFreeThreshold setting) behaviors? > > This is only to confirm that we are seeing the same issue. I removed the default GC settings of Cassandra, and I was using these two very basic configurations with 8G heap, so the 4G soft heap and the 50% min free threshold should have similar results: SoftMaxHeapSize test: -XX:+UseShenandoahGC -XX:ShenandoahSoftMaxHeapSize=4G -XX:+PrintGCDetails -Xloggc:... MinFreeThreshold test: -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahMinFreeThreshold=50 -XX:+PrintGCDetails -Xloggc:... Logs using ShenandoahSoftMaxHeapSize=4G with 8G heap: This is an example with an "Adaptive CSet Selection" step: Trigger: Free (818M) is below minimum threshold (819M) Free: 818M, Max: 4096K regular, 796M humongous, Frag: 1% external, 2% internal; Reserve: 412M, Max: 4096K 295.759: [Concurrent reset, start] Using 1 of 2 workers for concurrent reset Pacer for Reset. Non-Taxable: 8192M 295.781: [Concurrent reset, 22.063 ms] 295.782: [Pause Init Mark, start] Using 2 of 2 workers for init marking Pacer for Mark. Expected Live: 42067K, Free: 817M, Non-Taxable: 83700K, Alloc Tax Rate: 0.1x 295.785: [Pause Init Mark, 3.170 ms] 295.785: [Concurrent marking, start] Using 1 of 2 workers for concurrent marking 295.858: [Concurrent marking, 72.770 ms] 295.859: [Pause Final Mark, start] Using 2 of 2 workers for final marking Adaptive CSet Selection. Target Free: 1160M, Actual Free: 7441M, Max CSet: 341M, Min Garbage: 0B Collectable Garbage: 6917M (99%), Immediate: 6233M (90%), CSet: 683M (9%) Pacer for Evacuation. Used CSet: 692M, Free: 7042M, Non-Taxable: 704M, Alloc Tax Rate: 1.1x 295.870: [Pause Final Mark, 11.155 ms] 295.871: [Concurrent cleanup, start] 295.871: [Concurrent cleanup 6970M->741M(8192M), 0.212 ms] Free: 7042M, Max: 4096K regular, 800M humongous, Frag: 89% external, 0% internal; Reserve: 408M, Max: 4096K 295.871: [Concurrent evacuation, start] Using 1 of 2 workers for concurrent evacuation 295.896: [Concurrent evacuation, 25.222 ms] 295.897: [Pause Init Update Refs, start] Pacer for Update Refs. Used: 751M, Free: 7039M, Non-Taxable: 703M, Alloc Tax Rate: 1.1x 295.898: [Pause Init Update Refs, 0.362 ms] 295.898: [Concurrent update references, start] Using 1 of 2 workers for concurrent reference update 295.948: [Concurrent update references, 50.645 ms] 295.953: [Pause Final Update Refs, start] Using 2 of 2 workers for final reference update 295.954: [Pause Final Update Refs, 1.184 ms] 295.954: [Concurrent cleanup, start] 295.954: [Concurrent cleanup 756M->66144K(8192M), 0.075 ms] Free: 7715M, Max: 4096K regular, 6540M humongous, Frag: 16% external, 0% internal; Reserve: 412M, Max: 4096K This seems to have very similar values but has no "Adaptive CSet Selection" step logged (from the same run as the above): Trigger: Free (818M) is below minimum threshold (819M) Free: 818M, Max: 4096K regular, 796M humongous, Frag: 1% external, 3% internal; Reserve: 412M, Max: 4096K 376.147: [Concurrent reset, start] Using 1 of 2 workers for concurrent reset Pacer for Reset. Non-Taxable: 8192M 376.157: [Concurrent reset, 10.150 ms] 376.158: [Pause Init Mark, start] Using 2 of 2 workers for init marking Pacer for Mark. Expected Live: 40091K, Free: 818M, Non-Taxable: 83802K, Alloc Tax Rate: 0.1x 376.160: [Pause Init Mark, 2.054 ms] 376.160: [Concurrent marking, start] Using 1 of 2 workers for concurrent marking 376.193: [Concurrent marking, 33.004 ms] 376.194: [Pause Final Mark, start] Using 2 of 2 workers for final marking Collectable Garbage: 6352M (91%), Immediate: 6352M (91%), CSet: 0B (0%) 376.194: [Pause Final Mark, 0.362 ms] 376.195: [Concurrent cleanup, start] 376.195: [Concurrent cleanup 6966M->618M(8192M), 0.208 ms] Free: 7161M, Max: 4096K regular, 796M humongous, Frag: 89% external, 0% internal; Reserve: 412M, Max: 4096K Free: 7161M, Max: 4096K regular, 796M humongous, Frag: 89% external, 0% internal; Reserve: 412M, Max: 4096K Even in the case when there is no "Adaptive CSet Selection" step logged, it seems to end up collecting the garbage, so the issue I am experiencing might have a different root cause than I originally thought. The free value in the trigger log seems to have the soft tail is subtracted, so that might explain why it is lower than 4G. On the other hand the garbage size is indicated to be more than the 4G soft heap size, so the free size might be the full value, including the soft tail. ShenandoahMinFreeThreshold=50 on the other hand seems to trigger when the free size goes slightly below 4G, and the garbage values are less than 4G too that seems to be more consistent: Trigger: Free (4095M) is below minimum threshold (4095M) Free: 4095M, Max: 4096K regular, 4064M humongous, Frag: 1% external, 0% internal; Reserve: 412M, Max: 4096K 146.861: [Concurrent reset, start] Using 1 of 2 workers for concurrent reset Pacer for Reset. Non-Taxable: 8192M 146.863: [Concurrent reset, 2.192 ms] 146.864: [Pause Init Mark, start] Using 2 of 2 workers for init marking Pacer for Mark. Expected Live: 81972K, Free: 4095M, Non-Taxable: 409M, Alloc Tax Rate: 0.0x 146.865: [Pause Init Mark, 1.769 ms] 146.865: [Concurrent marking, start] Using 1 of 2 workers for concurrent marking 146.927: [Concurrent marking, 61.843 ms] 146.934: [Pause Final Mark, start] Using 2 of 2 workers for final marking Adaptive CSet Selection. Target Free: 4437M, Actual Free: 7407M, Max CSet: 341M, Min Garbage: 0B Collectable Garbage: 3630M (99%), Immediate: 2931M (80%), CSet: 698M (19%) Pacer for Evacuation. Used CSet: 706M, Free: 7010M, Non-Taxable: 701M, Alloc Tax Rate: 1.1x 146.949: [Pause Final Mark, 14.292 ms] 146.949: [Concurrent cleanup, start] 146.949: [Concurrent cleanup 3700M->773M(8192M), 0.126 ms] Free: 7007M, Max: 4096K regular, 4064M humongous, Frag: 42% external, 0% internal; Reserve: 409M, Max: 4096K 146.949: [Concurrent evacuation, start] Using 1 of 2 workers for concurrent evacuation 146.960: [Concurrent evacuation, 10.771 ms] 146.960: [Pause Init Update Refs, start] Pacer for Update Refs. Used: 783M, Free: 7005M, Non-Taxable: 700M, Alloc Tax Rate: 1.1x 146.960: [Pause Init Update Refs, 0.045 ms] 146.961: [Concurrent update references, start] Using 1 of 2 workers for concurrent reference update 147.018: [Concurrent update references, 57.464 ms] 147.018: [Pause Final Update Refs, start] Using 2 of 2 workers for final reference update 147.020: [Pause Final Update Refs, 1.149 ms] 147.020: [Concurrent cleanup, start] 147.020: [Concurrent cleanup 798M->93730K(8192M), 0.081 ms] Free: 7688M, Max: 4096K regular, 4072M humongous, Frag: 47% external, 0% internal; Reserve: 412M, Max: 4096K I also found this near the end of the log, even when using ShenandoahSoftMaxHeapSize=4G: Cancelling GC: Stopping VM Heap Shenandoah Heap 8192M max, 8192M soft max, 8192M committed, 3986M used 2048 x 4096K regions Status: cancelled Is it possible that the initial ShenandoahSoftMaxHeapSize value is never set for the heap? I could only find it being set on run-time value changes (JDK8), but there was no such run-time change logged. Thank you, Kornel From vlivanov at openjdk.java.net Tue Jan 12 23:17:07 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 12 Jan 2021 23:17:07 GMT Subject: [jdk16] RFR: 8255120: C2: assert(outer->outcnt() >= phis + 2 && outer->outcnt() <= phis + 2 + stores + 1) failed: only phis Message-ID: <2PEWRbpWVrdRx47oZPJQVs082bVynDioRaD2GjZExqs=.3561364b-f502-416d-a0ac-1a6bc1087627@github.com> JDK-8255000 made post-loopopts IGVN processing predictable, but also reordered it with macro node expansion. It turned out that macro node expansion is sensitive to narrower types post-loopopts IGVN generates and it either triggers the aforementioned assert or produces less efficient code (some runtime checks aren't eliminated anymore and it adds up some overhead, see JDK-8255705 for details). I'll file a separate RFE to make macro node expansion more robust (and relax the problematic assert), but for now (jdk16) I propose to restore the original order of transformations. Testing: - [x] failing test - [x] hs-tier1 - hs-tier6 - [x] SPECjvm2008 MPEG - [x] gc/shenandoah/ ------------- Commit messages: - 8255120: C2: assert(outer->outcnt() >= phis + 2 && outer->outcnt() <= phis + 2 + stores + 1) failed: only phis Changes: https://git.openjdk.java.net/jdk16/pull/113/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=113&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255120 Stats: 40 lines in 5 files changed: 14 ins; 15 del; 11 mod Patch: https://git.openjdk.java.net/jdk16/pull/113.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/113/head:pull/113 PR: https://git.openjdk.java.net/jdk16/pull/113 From github.com+51720475+kdnilsen at openjdk.java.net Wed Jan 13 02:44:45 2021 From: github.com+51720475+kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Wed, 13 Jan 2021 02:44:45 GMT Subject: RFR: Scan remembered [v2] In-Reply-To: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> Message-ID: > Add support for scanning remembered set > > The code has support for two alternative implementations of the remembered set. The current remembered set implementation uses traditional card marking, where the post writer barrier for pointer write operations sets the mark for every overwritten card. > > A contemplated future remembered set implementation is represented in skeleton form within the shenandoahBufferWithSATBRememberedSet.hpp and shenandoahBufferWithSATBRememberedSet.inline.hpp files. The idea of this alternative remembered set implementation is that the existing SATB buffers will be augmented to additionally remember the address of each overwritten reference field. Subsequent processing of the SATB buffer contents by background GC threads will update the TBD remembered set representation. > > There are known bugs and performance improvements in the remembered set scanning implementation that have been addressed in certain Amazon-internal commits. These commits will be upstreamed at a later time after other commits not directly related to remembered set scanning are upstreamed. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Improvements requested during initial review These changes are cosmetic and/or related to comments. ------------- Changes: - all: https://git.openjdk.java.net/shenandoah/pull/12/files - new: https://git.openjdk.java.net/shenandoah/pull/12/files/37802abc..8462a729 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=12&range=01 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=12&range=00-01 Stats: 316 lines in 8 files changed: 26 ins; 253 del; 37 mod Patch: https://git.openjdk.java.net/shenandoah/pull/12.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/12/head:pull/12 PR: https://git.openjdk.java.net/shenandoah/pull/12 From kdnilsen at amazon.com Wed Jan 13 02:49:43 2021 From: kdnilsen at amazon.com (Nilsen, Kelvin) Date: Wed, 13 Jan 2021 02:49:43 +0000 Subject: RFR: Scan remembered In-Reply-To: References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> Message-ID: <5E2C7DE7-876A-4FB7-84CC-660F79D847DF@amazon.com> Thank you again for the prompt review of my prior pull request. I have attempted to respond to the various issues and have pushed a new commit to the pull request. ?On 1/11/21, 2:59 AM, "shenandoah-dev on behalf of Roman Kennke" wrote: >src/hotspot/share/gc/shenandoah/shenandoahBufferWithSATBRememberedSet.hpp >line 1: >> 1: // >New file lacks copyright notice. Fixed. >src/hotspot/share/gc/shenandoah/shenandoahBufferWithSATBRememberedSet.hpp >line 17: >> 15: // a) Just blindly dirty each card that is overwritten > with a pointer value, regardless of the written value, as with >> 16: // the implementation of traditional direct card > marking. When this card's memory region is eventually scanned, > the >> 17: // the implementation of remembered set scanning > will clear the page if it no longer holds references to > young-gen >Minor: double- 'the' Fixed. >src/hotspot/share/gc/shenandoah/shenandoahBufferWithSATBRememberedSet.hpp >line 61: >> 59: // existing SATB pre-write barrier to maintain remembered > set information rather than using unconditional direct card > marking in >> 60: // a post-write barrier. >> 61: class ShenandoahBufferWithSATBRememberedSet: public > CHeapObj { >So, if I understand correctly, you intend to piggy-back the >field-address onto the SATB queue, is that right? It would mean >that we need to double the size of the items in the buffer. And it >would also mean that SATB needs to be turned on all the time, not >just during marking. Is that correct? If that is so, I wonder if >it may be better to do like G1 does and use a separate queue and >barrier for this? It looks to me that it is doing exactly what we >need here. I sent a separate email to explain my thoughts regarding this. This is an "experimental" feature to be implemented if and when time permits. >src/hotspot/share/gc/shenandoah/shenandoahBufferWithSATBRememberedSet.inline.hpp >line 1: >> 1: >Missing copyright header too. > And header #ifndef-#define-#endif ;-) I've removed this source file. Will add it back in once implemented. >src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1159: >> 1157: ShenandoahEvacuateUpdateRootsClosure<> cl; >> 1158: MarkingCodeBlobClosure blobsCl(&cl, >> CodeBlobToOopClosure::FixRelocations); >> 1159: >Extra whitespace I gather you are referring to the extra blank line here. I've removed it. I don't see any other extra whitespace. >src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2730: >> 2728: // phase do not need to be scanned by > update-refs because the to-space invariant is in force >> 2729: // during evacuation and this will assure > that any objects residing between >> 2730: // r->get_update_watermark() and r->top() > hold no pointers to from-space. >We do need to scan objects that have been allocated by evacuation, >because they may hold from-space refs. For this reason, we bump-up >UWM when allocating for evac (in ShFreeSet, iirc). Thank you for pointing this out. I did not fully understand how this works. I've studied this a bit more and I have rewritten the comment. I would appreciate if you could confirm that my new understanding as documented in the updated comment is valid. >src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2720: >> 2718: // an old-gen region as part of an old-gen > collection. Otherwise, a subseqent update-refs scan of >> 2719: // the same region will see stale pointers and > crash. >> 2720: // >This is probably a bad idea. Unreachable objects are not >guaranteed to have their Klass* intact, and may crash when >accessed. Why would it crash during subsequent scans? This aspect of the implementation has evolved a bit from what is captured in the current pull request. Here's an overview description of the "problem" that can arise: 1. A global (or old-gen) collection discovers that certain objects within an old-gen card range are dead, but it does not choose the enclosing heap region for evacuation (it is not part of the collection set). 2. Since update refs during the global (old-gen) collection is guided by the mark bitmap, references contained within dead objects are not updated. 3. Assume that at some future time, a live object contained within the same card range is overwritten with a reference to young-gen. This has the effect of marking the card. 4. Thereafter, at the subsequent young-gen collection, remembered set scanning examines all of the objects contained within this card. It does not "know" to skip over the dead objects contained within this card. References contained within the dead objects, which were not updated during the previous old-gen collection, now contain garbage values and scanning of these references may result in a crash. As we incrementally upstream the results of our developments efforts, you will eventually see an improved solution that coalesces and fills dead objects found between marked objects so that any dead (we call them zombie) objects that happen to reside within a card's memory range will not result in problems when we scan the remembered set. We are also exploring an additional improvement to this algorithm. The idea here is to preserve the mark bitmap from the most recently completed global (old-gen) collection and use this to guide remembered set scanning. >src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2741: >> 2739: // allocate from within a free region. >> 2740: // >> 2741: // Reality is that this code is likely to be >> replaced with JVM-292 code before we ever get around to >What is 'JVM-292' code? ;-) I have replaced this comment to avoid reference to internal ticket number. >src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 71: >> 69: class VMStructs; >> 70: >> 71: >Extra WS I have removed one of the two blank lines. >src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 40: >> 38: #include "gc/shenandoah/shenandoahScanRemembered.hpp" >> 39: #include "memory/metaspace.hpp" >> 40: #include "gc/shenandoah/shenandoahScanRemembered.hpp" >You're including the same header 2x Thanks for catching this. I think this came in through a manual merge conflict. I've removed one of the includes. >src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 49: >> 47: class ShenandoahCollectorPolicy; >> 48: class ShenandoahControlThread; >> 49: class ShenandoahDirectCardMarkRememberedSet; >This looks unused. Agreed. Removed. >src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.hpp >line 30: >> 28: >> 29: #include "gc/shared/referenceDiscoverer.hpp" >> 30: #include "gc/shared/referencePolicy.hpp" >This looks not needed or, if it is actually needed, not related to >this change. The dependency on these #includes was introduced by one of the other commits pulled into the genshen branch prior to this pull request. Without these #includes, the code does not compile. I have moved the two includes to precede the include of shenandoahReferenceProcessor.hpp within shenandoahScanRemembered.hpp. >src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line >2: >> 1: /* >> 2: * Copyright (c) Amazon.com, Inc. or its affiliates. All >> rights reserved. >You do have the copyright header here, good! :-) But it's lacking >the year, like so: > * Copyright (c) 2021, Amazon.com, Inc. or its affiliates. All >rights reserved. Amazon legal/corporate is advising us to omit the date from copyright notices. Is it ok to keep these as is? >src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line >2: >> 1: /* >> 2: * Copyright (c) Amazon.com, Inc. or its affiliates. All >> rights reserved. >Missing copyright year, as above. See above. >src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line >103: >> 101: } >> 102: >> 103: // Implementation is not correct. >> ShenandoahBufferWithSATBRememberedSet is a placeholder for >> future planned improvements. >This should go into its own .cpp file I think. Actually, I am not >sure that we should add empty&unused code at all. Maybe add it >when you also fill the implementation and use? I have removed mention of ShenandoahBufferWithSATBRememberedSet from within shenandoahScanRemembered.cpp, removed the shenandoahBufferWithSATBRememberedSet.hpp and shenandoahBufferWithSATBRememberedSet.inline.hpp source files, and removed the #include directives for these two files from the files shenandoahScanRemembered.hpp and shenandoahScanRemembered.inline.hpp. I have also edited comments in shenandoahScanRemembered.hpp that make mention of ShenandoahBufferWithSATBRememberedSet. >src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line >90: >> 88: >> 89: // The typical parallel remembered set scanning effort >> consists of the >> 90: // following steps, all of which are performed during a JVM >> safetpoint: >Typo: safetpoint -> safepoint. Fixed. >src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line >212: >> 210: // into ShenandoahRootEvacuator::roots_do() before the > invocation of >> 211: // _serial_roots.oops_do(oops, worker_id). >> 212: >This is not quite clear to me. Above you said that all of the work >is done during safepoints. Here you mention 'concurrent >scanning' ... what is true? Thanks for calling this out. I had written this comment early in the development process, before I had a full understanding of how the code would integrate within the existing context. The remembered set scanning abstractions are designed to support concurrent remembered set scanning. However, our initial implementation of genshen does remembered set scanning during a safepoint. I have revised the comments to better reflect the current reality. >src/hotspot/share/gc/shenandoah/shenandoahBufferWithSATBRememberedSet.hpp >line 61: >> 59: // existing SATB pre-write barrier to maintain remembered > set information rather than using unconditional direct card > marking in >> 60: // a post-write barrier. >> 61: class ShenandoahBufferWithSATBRememberedSet: public > CHeapObj { >It's also lacking the usual #ifndef - #define - #endif sequence >that is needed by headers. I have removed this source file from the commit. >src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line >26: >> 24: */ >> 25: >> 26: // Terminology used within this source file: >We usually place big comments like this below #includes and just >above class declarations. Ok. Moved. >src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line >787: >> 785: // What card number corresponds to old-gen heap addresss > p. (If p >> 786: // does not refer to old-gen memory, the returned value > is undefined.) >> 787: uint32_t cardNoForAddr(HeapWord *p); >Should be named card_no_for_addr(HeapWord* p) to match style of >most other Hotspot code. I have removed the cardNoForAddr prototype. It was accidentally leftover from previous editing. It has been replaced with card_index_for_addr(), already present in the same source file. >src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp >line 2: >> 1: /* >> 2: * Copyright (c) Amazon.com, Inc. or its affiliates. All >> rights reserved. >Missing copyright year. Intentional. See above. >src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line >26: >> 24: */ >> 25: >> 26: >Make sure you're adding #include "precompiled.hpp" and make sure >it builds with and without --disable-precompiled-headers I've added "precompiled.hpp" and have successfully built both ways. >------------- >Changes requested by rkennke (Reviewer). >PR: https://git.openjdk.java.net/shenandoah/pull/12 From gnu.andrew at redhat.com Wed Jan 13 03:32:36 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Jan 2021 03:32:36 +0000 Subject: [RFR] [8u] 8u282-b05 Upstream Sync Message-ID: <20210113033236.GA74362@rincewind> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/root/merge.changeset Changes in aarch64-shenandoah-jdk8u282-b05: - JDK-8254982: (tz) Upgrade time-zone data to tzdata2020c Main issues of note: None, clean merge (no HotSpot changes). diffstat for root b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for corba b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxp b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxws b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for langtools b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for nashorn b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jdk b/.hgtags | 1 + b/make/data/tzdata/VERSION | 2 +- b/make/data/tzdata/australasia | 17 ++++++++++++++++- b/make/data/tzdata/europe | 6 +++++- b/test/java/util/Formatter/BasicDateTime.java | 11 +++++++++++ b/test/sun/util/calendar/zi/tzdata/VERSION | 2 +- b/test/sun/util/calendar/zi/tzdata/australasia | 17 ++++++++++++++++- b/test/sun/util/calendar/zi/tzdata/europe | 6 +++++- 8 files changed, 56 insertions(+), 6 deletions(-) diffstat for hotspot b/.hgtags | 1 + 1 file changed, 1 insertion(+) Successfully built on x86, x86_64, s390 (Zero), s390x (Zero), ppc (Zero), ppc64, ppc64le & aarch64. Ok to push? Thanks, -- Andrew :) 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 shade at openjdk.java.net Wed Jan 13 07:41:59 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 13 Jan 2021 07:41:59 GMT Subject: RFR: 8259580: Shenandoah: uninitialized label in VerifyThreadGCState In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 20:54:28 GMT, Roman Kennke wrote: >> "label" is passed, but never hooked into the field. So instead of reporting a GC bug, Verifier would probably crash itself trying to read garbage memory. > > src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 606: > >> 604: private: >> 605: const char* const _label; >> 606: char const _expected; > > Why can't _expected not be const char* const too? Are we really messing with the string on the way? @rkennke Still good with this explanation? ------------- PR: https://git.openjdk.java.net/jdk/pull/2033 From shade at redhat.com Wed Jan 13 07:44:21 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 13 Jan 2021 08:44:21 +0100 Subject: [RFR] [8u] 8u282-b05 Upstream Sync In-Reply-To: <20210113033236.GA74362@rincewind> References: <20210113033236.GA74362@rincewind> Message-ID: <0c2624c7-a45d-41ff-df8d-ac5c627ecc9d@redhat.com> On 1/13/21 4:32 AM, Andrew Hughes wrote: > Merge changesets: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/jaxws/merge.changeset Look trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/jdk/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/hotspot/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/root/merge.changeset Look trivially good. > Ok to push? Yes. -- Thanks, -Aleksey From thartmann at openjdk.java.net Wed Jan 13 08:03:59 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 13 Jan 2021 08:03:59 GMT Subject: [jdk16] RFR: 8255120: C2: assert(outer->outcnt() >= phis + 2 && outer->outcnt() <= phis + 2 + stores + 1) failed: only phis In-Reply-To: <2PEWRbpWVrdRx47oZPJQVs082bVynDioRaD2GjZExqs=.3561364b-f502-416d-a0ac-1a6bc1087627@github.com> References: <2PEWRbpWVrdRx47oZPJQVs082bVynDioRaD2GjZExqs=.3561364b-f502-416d-a0ac-1a6bc1087627@github.com> Message-ID: On Tue, 12 Jan 2021 22:16:54 GMT, Vladimir Ivanov wrote: > JDK-8255000 made post-loopopts IGVN processing predictable, but also reordered it with macro node expansion. > > It turned out that macro node expansion is sensitive to narrower types post-loopopts IGVN generates and it either triggers the aforementioned assert or produces less efficient code (some runtime checks aren't eliminated anymore and it adds up some overhead, see JDK-8255705 for details). > > I'll file a separate RFE to make macro node expansion more robust (and relax the problematic assert), but for now (jdk16) I propose to restore the original order of transformations. > > Testing: > - [x] failing test > - [x] hs-tier1 - hs-tier6 > - [x] SPECjvm2008 MPEG > - [x] gc/shenandoah/ Looks good to me. Can JDK-8255705 be closed as duplicate or are there other performance issues left? ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/113 From vlivanov at openjdk.java.net Wed Jan 13 08:25:01 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 13 Jan 2021 08:25:01 GMT Subject: [jdk16] RFR: 8255120: C2: assert(outer->outcnt() >= phis + 2 && outer->outcnt() <= phis + 2 + stores + 1) failed: only phis In-Reply-To: References: <2PEWRbpWVrdRx47oZPJQVs082bVynDioRaD2GjZExqs=.3561364b-f502-416d-a0ac-1a6bc1087627@github.com> Message-ID: On Wed, 13 Jan 2021 08:00:59 GMT, Tobias Hartmann wrote: >> JDK-8255000 made post-loopopts IGVN processing predictable, but also reordered it with macro node expansion. >> >> It turned out that macro node expansion is sensitive to narrower types post-loopopts IGVN generates and it either triggers the aforementioned assert or produces less efficient code (some runtime checks aren't eliminated anymore and it adds up some overhead, see JDK-8255705 for details). >> >> I'll file a separate RFE to make macro node expansion more robust (and relax the problematic assert), but for now (jdk16) I propose to restore the original order of transformations. >> >> Testing: >> - [x] failing test >> - [x] hs-tier1 - hs-tier6 >> - [x] SPECjvm2008 MPEG >> - [x] gc/shenandoah/ > > Looks good to me. Can JDK-8255705 be closed as duplicate or are there other performance issues left? Thanks, Tobias. > Can JDK-8255705 be closed as duplicate or are there other performance issues left? I don't have a conclusive answer yet. The fix does improve MPEG score a bit, but it is still slower than jdk-16+20. jdk-16.latest 150.391 +- 0.361 ops/min jdk-16.fix 151.212 +- 0.356 ops/min jdk-16+20 152.267 +- 0.378 ops/min jdk-16+21 150.343 +- 0.294 ops/min Will conduct additional performance experiments before deciding what to do with JDK-8255705. ------------- PR: https://git.openjdk.java.net/jdk16/pull/113 From rkennke at redhat.com Wed Jan 13 11:42:45 2021 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 13 Jan 2021 12:42:45 +0100 Subject: RFR: Scan remembered In-Reply-To: <5E2C7DE7-876A-4FB7-84CC-660F79D847DF@amazon.com> References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> <5E2C7DE7-876A-4FB7-84CC-660F79D847DF@amazon.com> Message-ID: <64f14b1e-d351-a7b8-ebf5-6f171cdd1ba1@redhat.com> Hi Kelvin, I am getting a little confused now, because you replied to the review email, but it's not reflected in GitHub. Well, anyway, let me reply here: >> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1159: > >>> 1157: ShenandoahEvacuateUpdateRootsClosure<> cl; >>> 1158: MarkingCodeBlobClosure blobsCl(&cl, >>> CodeBlobToOopClosure::FixRelocations); >>> 1159: > >> Extra whitespace > > I gather you are referring to the extra blank line here. I've removed > it. I don't see any other extra whitespace. Yes, this is what I meant. Thanks! >> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2730: > >>> 2728: // phase do not need to be scanned by >> update-refs because the to-space invariant is in force >>> 2729: // during evacuation and this will assure >> that any objects residing between >>> 2730: // r->get_update_watermark() and r->top() >> hold no pointers to from-space. > >> We do need to scan objects that have been allocated by evacuation, >> because they may hold from-space refs. For this reason, we bump-up >> UWM when allocating for evac (in ShFreeSet, iirc). > > Thank you for pointing this out. I did not fully understand how this > works. I've studied this a bit more and I have rewritten the comment. > I would appreciate if you could confirm that my new understanding as > documented in the updated comment is valid. > Almost. You said: // Note that incrementing watermark to // account for objects newly evacuated into the region may result in otherwise unnecessary updating // of references contained within newly allocated objects that happen to be located between the // initial value of watermark and the updated value of watermark. This should not happen, because we don't mix evac-allocations with regular allocations in the same region. >> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2720: > >>> 2718: // an old-gen region as part of an old-gen >> collection. Otherwise, a subseqent update-refs scan of >>> 2719: // the same region will see stale pointers and >> crash. >>> 2720: // > >> This is probably a bad idea. Unreachable objects are not >> guaranteed to have their Klass* intact, and may crash when >> accessed. Why would it crash during subsequent scans? > > This aspect of the implementation has evolved a bit from what is > captured in the current pull request. > > Here's an overview description of the "problem" that can arise: > > 1. A global (or old-gen) collection discovers that certain objects > within an old-gen card range are dead, but it does not choose the > enclosing heap region for evacuation (it is not part of the collection > set). > > 2. Since update refs during the global (old-gen) collection is guided > by the mark bitmap, references contained within dead objects are not > updated. > > 3. Assume that at some future time, a live object contained within the > same card range is overwritten with a reference to young-gen. This > has the effect of marking the card. > > 4. Thereafter, at the subsequent young-gen collection, remembered set > scanning examines all of the objects contained within this card. It > does not "know" to skip over the dead objects contained within this > card. References contained within the dead objects, which were not > updated during the previous old-gen collection, now contain garbage > values and scanning of these references may result in a crash. > > As we incrementally upstream the results of our developments efforts, > you will eventually see an improved solution that coalesces and fills > dead objects found between marked objects so that any dead (we call > them zombie) objects that happen to reside within a card's memory > range will not result in problems when we scan the remembered set. > > We are also exploring an additional improvement to this algorithm. > The idea here is to preserve the mark bitmap from the most recently > completed global (old-gen) collection and use this to guide remembered > set scanning. Ok. A long time ago, we did actually preserve the previous bitmap to guide with iterations between cycles and during marking, for example for supporting heap-dumps. I believe G1 also does this, and uses the previous bitmap to guide old-gen-card-scanning. >> src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.hpp >> line 30: > >>> 28: >>> 29: #include "gc/shared/referenceDiscoverer.hpp" >>> 30: #include "gc/shared/referencePolicy.hpp" > >> This looks not needed or, if it is actually needed, not related to >> this change. > > The dependency on these #includes was introduced by one of the other > commits pulled into the genshen branch prior to this pull request. > Without these #includes, the code does not compile. > > I have moved the two includes to precede the include of > shenandoahReferenceProcessor.hpp within shenandoahScanRemembered.hpp. It should really be added in shenandoahReferenceProcessor.hpp as forwarding declaration, and maybe in shenandoahReferenceProcessor.cpp as include. Maybe one of you guy can handle this upstream? It's rather trivial and should give you some commit-right-creds ;-) >> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line >> 2: > >>> 1: /* >>> 2: * Copyright (c) Amazon.com, Inc. or its affiliates. All >>> rights reserved. > >> You do have the copyright header here, good! :-) But it's lacking >> the year, like so: >> * Copyright (c) 2021, Amazon.com, Inc. or its affiliates. All >> rights reserved. > > Amazon legal/corporate is advising us to omit the date from copyright > notices. Is it ok to keep these as is? I don't think so. All files in OpenJDK have a year in their copyright header, and if I understand correctly, it is a legal requirement by US law. https://en.wikipedia.org/wiki/Copyright_notice#Form_of_notice_for_visually_perceptible_copies IANAL though. If your lawyers insist, then maybe we should bring it up elsewhere in the OpenJDK project? >> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line >> 103: > >>> 101: } >>> 102: >>> 103: // Implementation is not correct. >>> ShenandoahBufferWithSATBRememberedSet is a placeholder for >>> future planned improvements. > >> This should go into its own .cpp file I think. Actually, I am not >> sure that we should add empty&unused code at all. Maybe add it >> when you also fill the implementation and use? > > I have removed mention of ShenandoahBufferWithSATBRememberedSet from > within shenandoahScanRemembered.cpp, removed the > shenandoahBufferWithSATBRememberedSet.hpp and > shenandoahBufferWithSATBRememberedSet.inline.hpp source files, and > removed the #include directives for these two files from the files > shenandoahScanRemembered.hpp and shenandoahScanRemembered.inline.hpp. > I have also edited comments in shenandoahScanRemembered.hpp that make > mention of ShenandoahBufferWithSATBRememberedSet. Ok, good. >> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line >> 212: > >>> 210: // into ShenandoahRootEvacuator::roots_do() before the >> invocation of >>> 211: // _serial_roots.oops_do(oops, worker_id). >>> 212: > >> This is not quite clear to me. Above you said that all of the work >> is done during safepoints. Here you mention 'concurrent >> scanning' ... what is true? > > Thanks for calling this out. I had written this comment early in the > development process, before I had a full understanding of how the code > would integrate within the existing context. > > The remembered set scanning abstractions are designed to support > concurrent remembered set scanning. However, our initial > implementation of genshen does remembered set scanning during a > safepoint. > > I have revised the comments to better reflect the current reality. Ok, good! Alright, I will do another review-pass in Github. In general, I find it very useful to do all review interactions in Github. The advantage is that all comments get closely associated to the code, and especially for large reviews Github makes it much easier to keep track of everything. If you think you 'resolved' a comment, then you can mark it as such, and it would not show up again on my side. Thanks, Roman From rkennke at redhat.com Wed Jan 13 11:49:08 2021 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 13 Jan 2021 12:49:08 +0100 Subject: RFR: Scan remembered In-Reply-To: <9471221F-115C-4132-9661-D996BC6DF13E@amazon.com> References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> <9471221F-115C-4132-9661-D996BC6DF13E@amazon.com> Message-ID: <4b434395-2ae7-5cd8-ab46-c9e0af6e8d47@redhat.com> > Thank you for the quick and detailed response. I will work on addressing the various issues you've raised. Below, I embed a response to one of your questions. > > ?On 1/11/21, 2:59 AM, "shenandoah-dev on behalf of Roman Kennke" wrote: > >> So, if I understand correctly, you intend to piggy-back the field-address onto the SATB queue, is that right? >> It would mean that we need to double the size of the items in the buffer. And it would also mean that SATB >> to be turned on all the time, not just during marking. Is that correct? If that is so, I wonder if it may be better >> to do like G1 does and use a separate queue and barrier for this? It looks to me that it is doing exactly what >> we need here. > > Here are a few aspects of the current design, some of which might change as we gather feedback from initial implementation efforts: > > 1. The thought was to use one bit within each pointer pushed into the SATB buffer to distinguish between the traditional SATB contents (reference values overwritten) and the new reference values (addresses of fields overwritten). Alternatively, we might push traditional SATB values to the start of the SATB buffer and push overwritten addresses to the end of the SATB buffer. Ok. I like that encoding-with-bits approach. :-) > 2. The traditional SATB write barrier is only enabled while either young-gen or old-gen (or both) concurrent marking is active. Ok good. > 3. A lighter weight pre-write barrier is active at other times. This lighter weight barrier does not need to pre-fetch value overwritten before performing the write so the cost of this form of the barrier is much lower than the cost of the traditional SATB pre-write barrier. Right. BTW, notice our I-U-mode also has a lighter form of barrier there, maybe you can "be inspired" by that too. It probably makes sense to keep the I-U-mode in mind in your efforts, as that could eventually become the default and replace SATB (not saying yet, that it will, but it has a few strong advantages -- the lighter barrier being one of them). > 4. We have prototyped an implementation of the "enhanced pre-write barrier" for which the code is roughly. We have not yet implemented the C1 and C2 versions of this barrier: > if (SATB buffer has fewer than 2 available slots) > take-the-slow-path(); > else { > push_to_satb_as_address (address overwritten into SATB buffer); > if (SATB is enabled) { > satb_value = fetch overwritten value(); > push_to_satb_as_overwritten_value (satb_value); > } > } That sounds good! > 5. We have looked at (but not fully digested) the G1 separate queue and write barrier. Indeed, it is very similar to what we need and ultimately, we may borrow from and/or reuse that implementation. However, we are also thinking that it might be more efficient to piggy-back on the existing SATB infrastructure in that this approach requires fewer dedicated registers (and/or less access to dedicated thread-local fields), fewer checks along common paths (check one buffer overflow instead of two), and smaller in-lined code for fast paths. We have one pointer to the SATB buffer, and one count (or index) of how much room remains within the SATB buffer. Given that old-gen and young-gen marking may happen concurrently, and that a single old-gen concurrent mark may span the time required for multiple complete young-gen GC cycles, we anticipate that the genshen SATB write barrier is likely to be enabled for a higher overall percentage of total execution time than is typical with traditional Shenandoah. This remains to be measured on aggressively scheduled workloads. (A genshen design objective is so support higher utilization of memory with same a given allocation rate, and without pauses. This probably means GC concurrent marking is active a larger percentage of time.) It is very well possible that G1's approach is not actually less efficient. > 6. We realize this increases the amount of data traffic funneled through the SATB buffer, so we are anticipating that we would want to increase the size of each SATB buffer. Yes. This needs to be experimented with. > We welcome additional thoughts and recommendations. So far sounds good to me! Thank you! Roman From rkennke at openjdk.java.net Wed Jan 13 11:52:56 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 13 Jan 2021 11:52:56 GMT Subject: RFR: 8259580: Shenandoah: uninitialized label in VerifyThreadGCState In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 19:02:55 GMT, Aleksey Shipilev wrote: > "label" is passed, but never hooked into the field. So instead of reporting a GC bug, Verifier would probably crash itself trying to read garbage memory. Looks good to me! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2033 From rkennke at openjdk.java.net Wed Jan 13 11:52:58 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 13 Jan 2021 11:52:58 GMT Subject: RFR: 8259580: Shenandoah: uninitialized label in VerifyThreadGCState In-Reply-To: References: Message-ID: <4DOMCo7tkldCumfiRMEgQj6fuIgvjN6MiyzlHU3SDGw=.a2b3a652-9ff2-4830-adab-2b19c00d77fe@github.com> On Wed, 13 Jan 2021 07:39:06 GMT, Aleksey Shipilev wrote: >> src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 606: >> >>> 604: private: >>> 605: const char* const _label; >>> 606: char const _expected; >> >> Why can't _expected not be const char* const too? Are we really messing with the string on the way? > > @rkennke Still good with this explanation? Yes, thank you! Stupid me overlooked the missing * :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/2033 From shade at openjdk.java.net Wed Jan 13 11:58:56 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 13 Jan 2021 11:58:56 GMT Subject: Integrated: 8259580: Shenandoah: uninitialized label in VerifyThreadGCState In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 19:02:55 GMT, Aleksey Shipilev wrote: > "label" is passed, but never hooked into the field. So instead of reporting a GC bug, Verifier would probably crash itself trying to read garbage memory. This pull request has now been integrated. Changeset: 2e124544 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/2e124544 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8259580: Shenandoah: uninitialized label in VerifyThreadGCState Reviewed-by: zgu, rkennke ------------- PR: https://git.openjdk.java.net/jdk/pull/2033 From rkennke at openjdk.java.net Wed Jan 13 12:27:17 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 13 Jan 2021 12:27:17 GMT Subject: RFR: Scan remembered [v2] In-Reply-To: References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> Message-ID: On Wed, 13 Jan 2021 02:44:45 GMT, Kelvin Nilsen wrote: >> Add support for scanning remembered set >> >> The code has support for two alternative implementations of the remembered set. The current remembered set implementation uses traditional card marking, where the post writer barrier for pointer write operations sets the mark for every overwritten card. >> >> A contemplated future remembered set implementation is represented in skeleton form within the shenandoahBufferWithSATBRememberedSet.hpp and shenandoahBufferWithSATBRememberedSet.inline.hpp files. The idea of this alternative remembered set implementation is that the existing SATB buffers will be augmented to additionally remember the address of each overwritten reference field. Subsequent processing of the SATB buffer contents by background GC threads will update the TBD remembered set representation. >> >> There are known bugs and performance improvements in the remembered set scanning implementation that have been addressed in certain Amazon-internal commits. These commits will be upstreamed at a later time after other commits not directly related to remembered set scanning are upstreamed. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > Improvements requested during initial review > > These changes are cosmetic and/or related to comments. The copyright stuff needs to be sorted out, but other than that it looks good to me now. Please notice my other few comments too. Good work! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 76: > 74: #include "gc/shenandoah/mode/shenandoahPassiveMode.hpp" > 75: #include "gc/shenandoah/mode/shenandoahSATBMode.hpp" > 76: #include "gc/shenandoah/shenandoahScanRemembered.inline.hpp" I noticed now, that you also include shenandoahScanRemembered.hpp above. You only need to include the .inline.hpp, and bonus points for keeping it in alphabethical order... ;-) src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2755: > 2753: // ShenandoahHeap::marked_object_iterate(), which is called by _heap->marked_object_oop_iterate(). > 2754: objs.do_object(obj); > 2755: p += obj->size(); As noted before, this might crash, if the Klass* that an unreachable object points to has been unloaded. The problem, as far as I can tell, arises because we don't have up-to-date marking information anymore, because we clean the whole bitmap, and subsequent young-gen collection doesn't establish old-gen reachability. Could we solve this by preserving the most-recent old-gen marking in the bitmap, and only clean the young-gen-parts? For now, it can probably be worked around by turning off ClassUnloading altogether. src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.hpp line 31: > 29: // #include "gc/shared/referenceDiscoverer.hpp" > 30: // #include "gc/shared/referencePolicy.hpp" > 31: #include "memory/allocation.hpp" Please fix that properly in an upstream change. I leave it up to you to keep the parts here, next merge should override it. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/12 From zgu at openjdk.java.net Wed Jan 13 13:09:18 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 13 Jan 2021 13:09:18 GMT Subject: RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes [v29] In-Reply-To: References: Message-ID: > This is the first part of refactoring, that aims to isolate three Shenandoah GC modes (concurrent, degenerated and full gc). > > Shenandoah started with two GC modes, concurrent and full gc, with minimal shared code, mainly in mark phase. After introducing degenerated GC, it shared quite large portion of code with concurrent GC, with the concept that degenerated GC can simply pick up remaining work of concurrent GC in STW mode. > > It was not a big problem at that time, since concurrent GC also processed roots STW. Since Shenandoah gradually moved root processing into concurrent phase, code started to diverge, that made code hard to reason and maintain. > > First step, I would like to split STW and concurrent mark, so that: > 1) Code has to special case for STW and concurrent mark. > 2) STW mark does not need to rendezvous workers between root mark and the rest of mark > 3) STW mark does not need to activate SATB barrier and drain SATB buffers. > 4) STW mark does not need to remark some of roots. > > The patch mainly just shuffles code. Creates a base class ShenandoahMark, and moved shared code (from current shenandoahConcurrentMark) into this base class. I did 'git mv shenandoahConcurrentMark.inline.hpp shenandoahMark.inline.hpp, but git does not seem to reflect that. > > A few changes: > 1) Moved task queue set from ShenandoahConcurrentMark to ShenandoahHeap. ShenandoahMark and its subclasses are stateless. Instead, mark states are maintained in task queue, mark bitmap and SATB buffers, so that they can be created on demand. > 2) Split ShenandoahConcurrentRootScanner template to ShenandoahConcurrentRootScanner and ShenandoahSTWRootScanner > 3) Split code inside op_final_mark code into finish_mark and prepare_evacuation helper functions. > 4) Made ShenandoahMarkCompact stack allocated (as well as ShenandoahConcurrentGC and ShenandoahDegeneratedGC in upcoming refactoring) Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits: - Merge branch 'master' into JDK-8255019-sh-mark - Fixes based on shade's comments - Merge branch 'master' into JDK-8255019-sh-mark - Silent MacOSX build - @shade's comments - Merge - Update copyright years - Merge - Merge branch 'master' into JDK-8255019-sh-mark - Concurrent mark does not expect forwarded objects - ... and 26 more: https://git.openjdk.java.net/jdk/compare/ce945120...4fbbfd27 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1009/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1009&range=28 Stats: 1971 lines in 21 files changed: 1072 ins; 756 del; 143 mod Patch: https://git.openjdk.java.net/jdk/pull/1009.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1009/head:pull/1009 PR: https://git.openjdk.java.net/jdk/pull/1009 From zgu at openjdk.java.net Wed Jan 13 13:09:19 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 13 Jan 2021 13:09:19 GMT Subject: RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes [v27] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 17:42:08 GMT, Aleksey Shipilev wrote: >> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: >> >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Silent MacOSX build >> - @shade's comments >> - Merge >> - Update copyright years >> - Merge >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Concurrent mark does not expect forwarded objects >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Merge branch 'master' into JDK-8255019-sh-mark >> - ... and 24 more: https://git.openjdk.java.net/jdk/compare/4d3d5991...a6540b99 > > Changes requested by shade (Reviewer). @shade, did I address all your concerns? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1009 From zgu at openjdk.java.net Wed Jan 13 13:56:24 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 13 Jan 2021 13:56:24 GMT Subject: RFR: Scan remembered [v2] In-Reply-To: References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> Message-ID: On Wed, 13 Jan 2021 02:44:45 GMT, Kelvin Nilsen wrote: >> Add support for scanning remembered set >> >> The code has support for two alternative implementations of the remembered set. The current remembered set implementation uses traditional card marking, where the post writer barrier for pointer write operations sets the mark for every overwritten card. >> >> A contemplated future remembered set implementation is represented in skeleton form within the shenandoahBufferWithSATBRememberedSet.hpp and shenandoahBufferWithSATBRememberedSet.inline.hpp files. The idea of this alternative remembered set implementation is that the existing SATB buffers will be augmented to additionally remember the address of each overwritten reference field. Subsequent processing of the SATB buffer contents by background GC threads will update the TBD remembered set representation. >> >> There are known bugs and performance improvements in the remembered set scanning implementation that have been addressed in certain Amazon-internal commits. These commits will be upstreamed at a later time after other commits not directly related to remembered set scanning are upstreamed. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > Improvements requested during initial review > > These changes are cosmetic and/or related to comments. Changes requested by zgu (Reviewer). src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 323: > 321: // Increment age in young copies. > 322: if (target_gen == YOUNG_GENERATION) { > 323: copy_val->incr_age(); Now, age is increased during young gen copy. Please update ShenandoahStringDedup::enqueue_candidate() to remove age updating code. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/12 From shade at openjdk.java.net Wed Jan 13 15:06:11 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 13 Jan 2021 15:06:11 GMT Subject: RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes [v27] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 17:38:41 GMT, Aleksey Shipilev wrote: >> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: >> >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Silent MacOSX build >> - @shade's comments >> - Merge >> - Update copyright years >> - Merge >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Concurrent mark does not expect forwarded objects >> - Merge branch 'master' into JDK-8255019-sh-mark >> - Merge branch 'master' into JDK-8255019-sh-mark >> - ... and 24 more: https://git.openjdk.java.net/jdk/compare/4d3d5991...a6540b99 > > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2212: > >> 2210: if (point == _degenerated_mark) { >> 2211: finish_mark(); >> 2212: } > > So if we don't call `finish_mark`, do we ever call `set_concurrent_mark_in_progress(false);` and `mark_complete_marking_context();`? This was not answered, and I don't see relevant follow-up changes. Is this a bug? ------------- PR: https://git.openjdk.java.net/jdk/pull/1009 From rkennke at openjdk.java.net Wed Jan 13 15:09:05 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 13 Jan 2021 15:09:05 GMT Subject: RFR: 8259377: Shenandoah: Enhance weak reference processing timing tracking [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 19:56:16 GMT, Zhengyu Gu wrote: >> Please review this enhancement for tracking weak references processing. >> >> Test: >> - [x] hotspot_gc_shenandoah > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentations Looks good to me! GH title and Jira title disagree. ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1979 From zgu at openjdk.java.net Wed Jan 13 15:22:04 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 13 Jan 2021 15:22:04 GMT Subject: RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes [v27] In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 15:03:24 GMT, Aleksey Shipilev wrote: >> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2212: >> >>> 2210: if (point == _degenerated_mark) { >>> 2211: finish_mark(); >>> 2212: } >> >> So if we don't call `finish_mark`, do we ever call `set_concurrent_mark_in_progress(false);` and `mark_complete_marking_context();`? > > This was not answered, and I don't see relevant follow-up changes. Is this a bug? No, I don't think so. For fall through case, STWMark sets both flags. For degen case, if we pass _degnerated_mark point, op_final_mark calls finish_mark to set them. ------------- PR: https://git.openjdk.java.net/jdk/pull/1009 From zgu at openjdk.java.net Wed Jan 13 19:04:01 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 13 Jan 2021 19:04:01 GMT Subject: Integrated: 8259377: Shenandoah: Enhance weak reference processing time tracking In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 17:58:19 GMT, Zhengyu Gu wrote: > Please review this enhancement for tracking weak references processing. > > Test: > - [x] hotspot_gc_shenandoah This pull request has now been integrated. Changeset: ccdf171d Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/ccdf171d Stats: 41 lines in 5 files changed: 12 ins; 2 del; 27 mod 8259377: Shenandoah: Enhance weak reference processing time tracking Reviewed-by: rkennke ------------- PR: https://git.openjdk.java.net/jdk/pull/1979 From github.com+71722661+earthling-amzn at openjdk.java.net Wed Jan 13 19:49:27 2021 From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn) Date: Wed, 13 Jan 2021 19:49:27 GMT Subject: RFR: Scan remembered [v2] In-Reply-To: References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> Message-ID: On Wed, 13 Jan 2021 12:17:34 GMT, Roman Kennke wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> Improvements requested during initial review >> >> These changes are cosmetic and/or related to comments. > > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2755: > >> 2753: // ShenandoahHeap::marked_object_iterate(), which is called by _heap->marked_object_oop_iterate(). >> 2754: objs.do_object(obj); >> 2755: p += obj->size(); > > As noted before, this might crash, if the Klass* that an unreachable object points to has been unloaded. The problem, as far as I can tell, arises because we don't have up-to-date marking information anymore, because we clean the whole bitmap, and subsequent young-gen collection doesn't establish old-gen reachability. Could we solve this by preserving the most-recent old-gen marking in the bitmap, and only clean the young-gen-parts? For now, it can probably be worked around by turning off ClassUnloading altogether. We've experimented with a preserved bitmap on a branch. It works until we hit a full collection, at which point things go sideways. The compaction phase specifically needed to be modified to maintain the correctness of the bitmap we wanted to preserve. It needs a bit more debugging, but it's been tabled for now. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/12 From kemperw at amazon.com Wed Jan 13 22:07:48 2021 From: kemperw at amazon.com (Kemper, William) Date: Wed, 13 Jan 2021 22:07:48 +0000 Subject: Question about Shenandoah pacer Message-ID: <1610575668663.74880@amazon.com> I'm considering a change that would have the heap notify the pacer directly of allocations. Currently, the heap notifies ShenandoahControlThread of words allocated, where they are accumulated into an _alloc_seen member. On iterations of the control thread loop that do not perform a GC, the accumulated _allocs_seen are passed to the pacer (otherwise, they are dropped and reset at the start of the next loop). Would there be harm in having the heap send these alloc'd words directly to the pacer? I'm also a little confused because these 'allocs_seen' are added to the pacer's budget - I thought allocations consumed the budget? Thank you, William From github.com+51720475+kdnilsen at openjdk.java.net Thu Jan 14 05:12:19 2021 From: github.com+51720475+kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Thu, 14 Jan 2021 05:12:19 GMT Subject: RFR: Scan remembered [v2] In-Reply-To: References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> Message-ID: On Wed, 13 Jan 2021 13:49:41 GMT, Zhengyu Gu wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> Improvements requested during initial review >> >> These changes are cosmetic and/or related to comments. > > src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 323: > >> 321: // Increment age in young copies. >> 322: if (target_gen == YOUNG_GENERATION) { >> 323: copy_val->incr_age(); > > I am not sure incr_age() work with concurrent version. e.g. if the object has displaced mark and two threads try to evacuate the object, both will increase age on displaced mark word. We did discover the need to deal with displaced mark words and a subsequent commit replaces the call to incr_age() with a call to a newly introduced incrase_object_age() function which includes special handling for displaced mark words. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/12 From github.com+51720475+kdnilsen at openjdk.java.net Thu Jan 14 05:24:24 2021 From: github.com+51720475+kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Thu, 14 Jan 2021 05:24:24 GMT Subject: RFR: Scan remembered [v2] In-Reply-To: References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> Message-ID: On Wed, 13 Jan 2021 12:10:07 GMT, Roman Kennke wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> Improvements requested during initial review >> >> These changes are cosmetic and/or related to comments. > > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 76: > >> 74: #include "gc/shenandoah/mode/shenandoahPassiveMode.hpp" >> 75: #include "gc/shenandoah/mode/shenandoahSATBMode.hpp" >> 76: #include "gc/shenandoah/shenandoahScanRemembered.inline.hpp" > > I noticed now, that you also include shenandoahScanRemembered.hpp above. You only need to include the .inline.hpp, and bonus points for keeping it in alphabethical order... ;-) Thanks. This fix will be reflected in my next push. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/12 From github.com+51720475+kdnilsen at openjdk.java.net Thu Jan 14 05:35:18 2021 From: github.com+51720475+kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Thu, 14 Jan 2021 05:35:18 GMT Subject: RFR: Scan remembered [v2] In-Reply-To: References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> Message-ID: On Thu, 14 Jan 2021 05:09:07 GMT, Kelvin Nilsen wrote: >> src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 323: >> >>> 321: // Increment age in young copies. >>> 322: if (target_gen == YOUNG_GENERATION) { >>> 323: copy_val->incr_age(); >> >> I am not sure incr_age() work with concurrent version. e.g. if the object has displaced mark and two threads try to evacuate the object, both will increase age on displaced mark word. > > We did discover the need to deal with displaced mark words and a subsequent commit replaces the call to incr_age() with a call to a newly introduced incrase_object_age() function which includes special handling for displaced mark words. I have also removed the code in ShenandoahStringDedup::enqueue_candidate() which increments the age of strings since we are now incrementing age during evacuation. This change will be reflected in the next commit that I push. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/12 From github.com+51720475+kdnilsen at openjdk.java.net Thu Jan 14 05:35:19 2021 From: github.com+51720475+kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Thu, 14 Jan 2021 05:35:19 GMT Subject: RFR: Scan remembered [v2] In-Reply-To: References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> Message-ID: <0zhe4GZ34Cv6LeNhKPX24NZWH134HWuHrodqGa8GjuM=.a1789860-0cba-48df-924b-4b4bf43ef93f@github.com> On Wed, 13 Jan 2021 12:19:02 GMT, Roman Kennke wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> Improvements requested during initial review >> >> These changes are cosmetic and/or related to comments. > > src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.hpp line 31: > >> 29: // #include "gc/shared/referenceDiscoverer.hpp" >> 30: // #include "gc/shared/referencePolicy.hpp" >> 31: #include "memory/allocation.hpp" > > Please fix that properly in an upstream change. I leave it up to you to keep the parts here, next merge should override it. I will figure out how to upstream that change. Thanks. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/12 From gnu.andrew at redhat.com Thu Jan 14 06:04:29 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Jan 2021 06:04:29 +0000 Subject: [RFR] [8u] 8u282-b06 Upstream Sync Message-ID: <20210114060429.GA277054@rincewind> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/root/merge.changeset Changes in aarch64-shenandoah-jdk8u282-b06: - JDK-8255226: (tz) Upgrade time-zone data to tzdata2020d Main issues of note: None, clean merge (no HotSpot changes). diffstat for root b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for corba b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxp b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxws b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for langtools b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for nashorn b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jdk b/.hgtags | 1 b/make/data/tzdata/VERSION | 2 b/make/data/tzdata/asia | 55 ++++++++++++---- b/make/data/tzdata/europe | 11 +-- b/src/share/classes/sun/util/calendar/ZoneInfoFile.java | 14 ++-- b/test/sun/util/calendar/zi/tzdata/VERSION | 2 b/test/sun/util/calendar/zi/tzdata/asia | 55 ++++++++++++---- b/test/sun/util/calendar/zi/tzdata/europe | 11 +-- 8 files changed, 109 insertions(+), 42 deletions(-) diffstat for hotspot b/.hgtags | 1 + 1 file changed, 1 insertion(+) Successfully built on x86, x86_64, s390 (Zero), s390x (Zero), ppc (Zero), ppc64, ppc64le & aarch64. Ok to push? Thanks, -- Andrew :) 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 shade at openjdk.java.net Thu Jan 14 09:26:09 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 14 Jan 2021 09:26:09 GMT Subject: RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes [v29] In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 13:09:18 GMT, Zhengyu Gu wrote: >> This is the first part of refactoring, that aims to isolate three Shenandoah GC modes (concurrent, degenerated and full gc). >> >> Shenandoah started with two GC modes, concurrent and full gc, with minimal shared code, mainly in mark phase. After introducing degenerated GC, it shared quite large portion of code with concurrent GC, with the concept that degenerated GC can simply pick up remaining work of concurrent GC in STW mode. >> >> It was not a big problem at that time, since concurrent GC also processed roots STW. Since Shenandoah gradually moved root processing into concurrent phase, code started to diverge, that made code hard to reason and maintain. >> >> First step, I would like to split STW and concurrent mark, so that: >> 1) Code has to special case for STW and concurrent mark. >> 2) STW mark does not need to rendezvous workers between root mark and the rest of mark >> 3) STW mark does not need to activate SATB barrier and drain SATB buffers. >> 4) STW mark does not need to remark some of roots. >> >> The patch mainly just shuffles code. Creates a base class ShenandoahMark, and moved shared code (from current shenandoahConcurrentMark) into this base class. I did 'git mv shenandoahConcurrentMark.inline.hpp shenandoahMark.inline.hpp, but git does not seem to reflect that. >> >> A few changes: >> 1) Moved task queue set from ShenandoahConcurrentMark to ShenandoahHeap. ShenandoahMark and its subclasses are stateless. Instead, mark states are maintained in task queue, mark bitmap and SATB buffers, so that they can be created on demand. >> 2) Split ShenandoahConcurrentRootScanner template to ShenandoahConcurrentRootScanner and ShenandoahSTWRootScanner >> 3) Split code inside op_final_mark code into finish_mark and prepare_evacuation helper functions. >> 4) Made ShenandoahMarkCompact stack allocated (as well as ShenandoahConcurrentGC and ShenandoahDegeneratedGC in upcoming refactoring) > > Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits: > > - Merge branch 'master' into JDK-8255019-sh-mark > - Fixes based on shade's comments > - Merge branch 'master' into JDK-8255019-sh-mark > - Silent MacOSX build > - @shade's comments > - Merge > - Update copyright years > - Merge > - Merge branch 'master' into JDK-8255019-sh-mark > - Concurrent mark does not expect forwarded objects > - ... and 26 more: https://git.openjdk.java.net/jdk/compare/ce945120...4fbbfd27 All right, fine, let's do it. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1009 From shade at redhat.com Thu Jan 14 11:46:34 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Jan 2021 12:46:34 +0100 Subject: Question about Shenandoah pacer In-Reply-To: <1610575668663.74880@amazon.com> References: <1610575668663.74880@amazon.com> Message-ID: <4738fc64-bcd8-939a-113e-599b381fe5cc@redhat.com> On 1/13/21 11:07 PM, Kemper, William wrote: > I'm considering a change that would have the heap notify the pacer directly of allocations. > Currently, the heap notifies ShenandoahControlThread of words allocated, where they are > accumulated into an _alloc_seen member. On iterations of the control thread loop that do not > perform a GC, the accumulated _allocs_seen are passed to the pacer (otherwise, they are dropped > and reset at the start of the next loop). Would there be harm in having the heap send these > alloc'd words directly to the pacer? > > I'm also a little confused because these 'allocs_seen' are added to the pacer's budget - I > thought allocations consumed the budget? What you see involves ShControlThread for a reason: it checks that ShControlThread is able to catch up with allocations outside of the cycle. In other words, ShControlThread replenishes the budget with the allocations it had seen and decided not to act. If you record allocations straight to pacer, you deconstruct this feedback loop. This whole thing matters because heap can run out of free space before control thread would be able to act. -- Thanks, -Aleksey From shade at redhat.com Thu Jan 14 11:48:47 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Jan 2021 12:48:47 +0100 Subject: [RFR] [8u] 8u282-b06 Upstream Sync In-Reply-To: <20210114060429.GA277054@rincewind> References: <20210114060429.GA277054@rincewind> Message-ID: <5097bca7-d6b9-c5e2-a657-fb5795cce39c@redhat.com> On 1/14/21 7:04 AM, Andrew Hughes wrote: > Merge changesets: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/jaxws/merge.changeset Look trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/jdk/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/hotspot/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/root/merge.changeset Look trivially good. > Ok to push? Yes. -- Thanks, -Aleksey From zgu at openjdk.java.net Thu Jan 14 14:43:15 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 14 Jan 2021 14:43:15 GMT Subject: RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes [v30] In-Reply-To: References: Message-ID: > This is the first part of refactoring, that aims to isolate three Shenandoah GC modes (concurrent, degenerated and full gc). > > Shenandoah started with two GC modes, concurrent and full gc, with minimal shared code, mainly in mark phase. After introducing degenerated GC, it shared quite large portion of code with concurrent GC, with the concept that degenerated GC can simply pick up remaining work of concurrent GC in STW mode. > > It was not a big problem at that time, since concurrent GC also processed roots STW. Since Shenandoah gradually moved root processing into concurrent phase, code started to diverge, that made code hard to reason and maintain. > > First step, I would like to split STW and concurrent mark, so that: > 1) Code has to special case for STW and concurrent mark. > 2) STW mark does not need to rendezvous workers between root mark and the rest of mark > 3) STW mark does not need to activate SATB barrier and drain SATB buffers. > 4) STW mark does not need to remark some of roots. > > The patch mainly just shuffles code. Creates a base class ShenandoahMark, and moved shared code (from current shenandoahConcurrentMark) into this base class. I did 'git mv shenandoahConcurrentMark.inline.hpp shenandoahMark.inline.hpp, but git does not seem to reflect that. > > A few changes: > 1) Moved task queue set from ShenandoahConcurrentMark to ShenandoahHeap. ShenandoahMark and its subclasses are stateless. Instead, mark states are maintained in task queue, mark bitmap and SATB buffers, so that they can be created on demand. > 2) Split ShenandoahConcurrentRootScanner template to ShenandoahConcurrentRootScanner and ShenandoahSTWRootScanner > 3) Split code inside op_final_mark code into finish_mark and prepare_evacuation helper functions. > 4) Made ShenandoahMarkCompact stack allocated (as well as ShenandoahConcurrentGC and ShenandoahDegeneratedGC in upcoming refactoring) Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: - Merge - Merge branch 'master' into JDK-8255019-sh-mark - Fixes based on shade's comments - Merge branch 'master' into JDK-8255019-sh-mark - Silent MacOSX build - @shade's comments - Merge - Update copyright years - Merge - Merge branch 'master' into JDK-8255019-sh-mark - ... and 27 more: https://git.openjdk.java.net/jdk/compare/ff3e6e46...8a6d94b8 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1009/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1009&range=29 Stats: 1965 lines in 21 files changed: 1069 ins; 757 del; 139 mod Patch: https://git.openjdk.java.net/jdk/pull/1009.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1009/head:pull/1009 PR: https://git.openjdk.java.net/jdk/pull/1009 From vlivanov at openjdk.java.net Thu Jan 14 17:22:11 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 14 Jan 2021 17:22:11 GMT Subject: [jdk16] Integrated: 8255120: C2: assert(outer->outcnt() >= phis + 2 && outer->outcnt() <= phis + 2 + stores + 1) failed: only phis In-Reply-To: <2PEWRbpWVrdRx47oZPJQVs082bVynDioRaD2GjZExqs=.3561364b-f502-416d-a0ac-1a6bc1087627@github.com> References: <2PEWRbpWVrdRx47oZPJQVs082bVynDioRaD2GjZExqs=.3561364b-f502-416d-a0ac-1a6bc1087627@github.com> Message-ID: On Tue, 12 Jan 2021 22:16:54 GMT, Vladimir Ivanov wrote: > JDK-8255000 made post-loopopts IGVN processing predictable, but also reordered it with macro node expansion. > > It turned out that macro node expansion is sensitive to narrower types post-loopopts IGVN generates and it either triggers the aforementioned assert or produces less efficient code (some runtime checks aren't eliminated anymore and it adds up some overhead, see JDK-8255705 for details). > > I'll file a separate RFE to make macro node expansion more robust (and relax the problematic assert), but for now (jdk16) I propose to restore the original order of transformations. > > Testing: > - [x] failing test > - [x] hs-tier1 - hs-tier6 > - [x] SPECjvm2008 MPEG > - [x] gc/shenandoah/ This pull request has now been integrated. Changeset: 0148adf2 Author: Vladimir Ivanov URL: https://git.openjdk.java.net/jdk16/commit/0148adf2 Stats: 40 lines in 5 files changed: 14 ins; 15 del; 11 mod 8255120: C2: assert(outer->outcnt() >= phis + 2 && outer->outcnt() <= phis + 2 + stores + 1) failed: only phis Reviewed-by: thartmann ------------- PR: https://git.openjdk.java.net/jdk16/pull/113 From zgu at openjdk.java.net Thu Jan 14 17:46:04 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 14 Jan 2021 17:46:04 GMT Subject: Integrated: 8255019: Shenandoah: Split STW and concurrent mark into separate classes In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 14:45:03 GMT, Zhengyu Gu wrote: > This is the first part of refactoring, that aims to isolate three Shenandoah GC modes (concurrent, degenerated and full gc). > > Shenandoah started with two GC modes, concurrent and full gc, with minimal shared code, mainly in mark phase. After introducing degenerated GC, it shared quite large portion of code with concurrent GC, with the concept that degenerated GC can simply pick up remaining work of concurrent GC in STW mode. > > It was not a big problem at that time, since concurrent GC also processed roots STW. Since Shenandoah gradually moved root processing into concurrent phase, code started to diverge, that made code hard to reason and maintain. > > First step, I would like to split STW and concurrent mark, so that: > 1) Code has to special case for STW and concurrent mark. > 2) STW mark does not need to rendezvous workers between root mark and the rest of mark > 3) STW mark does not need to activate SATB barrier and drain SATB buffers. > 4) STW mark does not need to remark some of roots. > > The patch mainly just shuffles code. Creates a base class ShenandoahMark, and moved shared code (from current shenandoahConcurrentMark) into this base class. I did 'git mv shenandoahConcurrentMark.inline.hpp shenandoahMark.inline.hpp, but git does not seem to reflect that. > > A few changes: > 1) Moved task queue set from ShenandoahConcurrentMark to ShenandoahHeap. ShenandoahMark and its subclasses are stateless. Instead, mark states are maintained in task queue, mark bitmap and SATB buffers, so that they can be created on demand. > 2) Split ShenandoahConcurrentRootScanner template to ShenandoahConcurrentRootScanner and ShenandoahSTWRootScanner > 3) Split code inside op_final_mark code into finish_mark and prepare_evacuation helper functions. > 4) Made ShenandoahMarkCompact stack allocated (as well as ShenandoahConcurrentGC and ShenandoahDegeneratedGC in upcoming refactoring) This pull request has now been integrated. Changeset: da6bcf96 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/da6bcf96 Stats: 1965 lines in 21 files changed: 1069 ins; 757 del; 139 mod 8255019: Shenandoah: Split STW and concurrent mark into separate classes Reviewed-by: rkennke, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/1009 From gnu.andrew at redhat.com Thu Jan 14 19:05:30 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Jan 2021 19:05:30 +0000 Subject: [RFR] [8u] 8u282-b05 Upstream Sync In-Reply-To: <0c2624c7-a45d-41ff-df8d-ac5c627ecc9d@redhat.com> References: <20210113033236.GA74362@rincewind> <0c2624c7-a45d-41ff-df8d-ac5c627ecc9d@redhat.com> Message-ID: <20210114190530.GA347533@rincewind> On 08:44 Wed 13 Jan , Aleksey Shipilev wrote: > On 1/13/21 4:32 AM, Andrew Hughes wrote: > > Merge changesets: > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/corba/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/jaxp/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/jaxws/merge.changeset > > Look trivially good. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/jdk/merge.changeset > > Looks good. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/hotspot/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/langtools/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/nashorn/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b05/root/merge.changeset > > Look trivially good. > > > Ok to push? > > Yes. > > -- > Thanks, > -Aleksey > Pushed. Thanks, -- Andrew :) 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 gnu.andrew at redhat.com Thu Jan 14 19:59:57 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Jan 2021 19:59:57 +0000 Subject: [RFR] [8u] 8u282-b06 Upstream Sync In-Reply-To: <5097bca7-d6b9-c5e2-a657-fb5795cce39c@redhat.com> References: <20210114060429.GA277054@rincewind> <5097bca7-d6b9-c5e2-a657-fb5795cce39c@redhat.com> Message-ID: <20210114195957.GB347533@rincewind> On 12:48 Thu 14 Jan , Aleksey Shipilev wrote: > On 1/14/21 7:04 AM, Andrew Hughes wrote: > > Merge changesets: > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/corba/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/jaxp/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/jaxws/merge.changeset > > Look trivially good. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/jdk/merge.changeset > > Looks good. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/hotspot/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/langtools/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/nashorn/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b06/root/merge.changeset > > Look trivially good. > > > Ok to push? > > Yes. > > -- > Thanks, > -Aleksey > Thanks. Pushed. -- Andrew :) 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 zgu at openjdk.java.net Thu Jan 14 21:19:11 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 14 Jan 2021 21:19:11 GMT Subject: RFR: 8255765: Shenandoah: Isolate concurrent, degenerated and full GC Message-ID: <9sUK197ZPOSEPLEDl8zKSqby-KMi9FryXnoctOdWmMc=.7b678df1-1c51-4bbf-b1a3-d8a8167a927d@github.com> The purpose of this patch is to isolate concurrent, degenerated and full gc implementation, so that, makes each GC implementation more straightforward and clean, and improves readability. Current implementation emphasis code sharing, e.g. degenerated GC reuses concurrent GC's ops. It was not a problem in the beginning, when they actually behave similarly. Since concurrent GC moved root processing into concurrent phases, code started to diverge, we started to put bandages to make the shared ops work for both concurrent and degenerated GC, that made code hard to read and error prone. The patch breaks up GCs into 3 (mainly just concurrent and degenerated GC, as full GC already standalone) easy to identify and understand classes (ShenandoahConcurrentGC, ShenandoahDegeneratedGC and ShenandoahMarkCompactGC), subclasses of ShenandoahGC class. The three GCs still keep vmop/entry/op paradigm, but encapsulate GC control flow inside their own classes, as ShenandoahMarkCompact GC already does. So that, concurrent and degenerated GC no longer share ops and op implementations no longer need to consider other GC modes, which results in simplifying implementation and improving readability. Code sharing is achieved via helper methods provided by ShenandoahHeap. ------------- Commit messages: - Remove cached heap in ShenandoahGC - Merge - Merge branch 'fix_phase_timings' into JDK-8255765-isolate-gcs - Merge - Merge - Merge - Merge - Removed trailing whitespaces - Merge - Merge branch 'JDK-8255019-sh-mark' into fix_phase_timings - ... and 89 more: https://git.openjdk.java.net/jdk/compare/a6b2162f...d9805040 Changes: https://git.openjdk.java.net/jdk/pull/1964/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1964&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255765 Stats: 3232 lines in 21 files changed: 1815 ins; 1281 del; 136 mod Patch: https://git.openjdk.java.net/jdk/pull/1964.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1964/head:pull/1964 PR: https://git.openjdk.java.net/jdk/pull/1964 From kornelpal at gmail.com Thu Jan 14 21:40:32 2021 From: kornelpal at gmail.com (Kornel Pal) Date: Thu, 14 Jan 2021 22:40:32 +0100 Subject: SoftMaxHeapSize has no effect with Cassandra In-Reply-To: References: Message-ID: <5101ff8a-b7f4-97ba-b739-d4d3a0401189@gmail.com> Hi, Kornel Pal wrote: > Is it possible that the initial ShenandoahSoftMaxHeapSize value is never set for the heap? I could only find it being set on run-time value changes (JDK8), but there was no such run-time change logged. I think I was able to figure out what is happening; soft max heap size is silently changed to min heap size in check_soft_max_changed(), when soft max heap size is less than min heap size. Cassandra on the other hand is setting min and max heap size to be the same by default, that results in soft max heap size to be ignored without any warning being logged. My understanding is that min heap size is used for uncommitting memory, while soft max heap size is use for collecting garbage, so I would not expect the two to depend on each other this way. This is the only dependency I could find (in ShenandoahControlThread::run()): size_t shrink_until = soft_max_changed ? heap->soft_max_capacity() : heap->min_capacity(); I am however not sure whether that is needed, because no other cases seem to use soft_max_capacity() for uncommitting memory, even subsequent iterations are reverting to min_capacity(), so soft_max_capacity() is used only right after it was changed. Thank you, Kornel From kdnilsen at openjdk.java.net Fri Jan 15 01:08:24 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Fri, 15 Jan 2021 01:08:24 GMT Subject: RFR: Scan remembered [v2] In-Reply-To: References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> Message-ID: On Mon, 11 Jan 2021 10:43:24 GMT, Roman Kennke wrote: >> src/hotspot/share/gc/shenandoah/shenandoahBufferWithSATBRememberedSet.inline.hpp line 1: >> >>> 1: >> >> Missing copyright header too. > > And header #ifndef-#define-#endif ;-) As discussed in email message, this file has been removed from the pull request. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/12 From kdnilsen at openjdk.java.net Fri Jan 15 01:18:21 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Fri, 15 Jan 2021 01:18:21 GMT Subject: RFR: Scan remembered [v2] In-Reply-To: References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> Message-ID: On Mon, 11 Jan 2021 10:10:54 GMT, Roman Kennke wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> Improvements requested during initial review >> >> These changes are cosmetic and/or related to comments. > > src/hotspot/share/gc/shenandoah/shenandoahBufferWithSATBRememberedSet.hpp line 61: > >> 59: // existing SATB pre-write barrier to maintain remembered set information rather than using unconditional direct card marking in >> 60: // a post-write barrier. >> 61: class ShenandoahBufferWithSATBRememberedSet: public CHeapObj { > > So, if I understand correctly, you intend to piggy-back the field-address onto the SATB queue, is that right? It would mean that we need to double the size of the items in the buffer. And it would also mean that SATB needs to be turned on all the time, not just during marking. Is that correct? If that is so, I wonder if it may be better to do like G1 does and use a separate queue and barrier for this? It looks to me that it is doing exactly what we need here. As discussed in email messages exchanged on shenandoah-dev at openjdk.java.net, there are potential synergies between the SATB-based remembered set implementation and the existing SATB pre-write barrier. Especially if the default Shenandoah configuration chooses not to use SATB barrier, that increases the appeal of borrowing the G1 barrier implementation. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/12 From kdnilsen at openjdk.java.net Fri Jan 15 01:21:24 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Fri, 15 Jan 2021 01:21:24 GMT Subject: RFR: Scan remembered [v2] In-Reply-To: References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> Message-ID: On Mon, 11 Jan 2021 10:17:33 GMT, Roman Kennke wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> Improvements requested during initial review >> >> These changes are cosmetic and/or related to comments. > > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1159: > >> 1157: ShenandoahEvacuateUpdateRootsClosure<> cl; >> 1158: MarkingCodeBlobClosure blobsCl(&cl, CodeBlobToOopClosure::FixRelocations); >> 1159: > > Extra whitespace This has been fixed. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/12 From kdnilsen at openjdk.java.net Fri Jan 15 01:40:23 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Fri, 15 Jan 2021 01:40:23 GMT Subject: RFR: Scan remembered [v2] In-Reply-To: References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> Message-ID: On Mon, 11 Jan 2021 10:42:55 GMT, Roman Kennke wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> Improvements requested during initial review >> >> These changes are cosmetic and/or related to comments. > > src/hotspot/share/gc/shenandoah/shenandoahBufferWithSATBRememberedSet.hpp line 61: > >> 59: // existing SATB pre-write barrier to maintain remembered set information rather than using unconditional direct card marking in >> 60: // a post-write barrier. >> 61: class ShenandoahBufferWithSATBRememberedSet: public CHeapObj { > > It's also lacking the usual #ifndef - #define - #endif sequence that is needed by headers. This file has been removed from the pull request. > src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 787: > >> 785: // What card number corresponds to old-gen heap addresss p. (If p >> 786: // does not refer to old-gen memory, the returned value is undefined.) >> 787: uint32_t cardNoForAddr(HeapWord *p); > > Should be named card_no_for_addr(HeapWord* p) to match style of most other Hotspot code. Removed. > src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp line 2: > >> 1: /* >> 2: * Copyright (c) Amazon.com, Inc. or its affiliates. All rights reserved. > > Missing copyright year. We've asked around inside Amazon. We're good to add in the copyright dates. So next commit will include these. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/12 From kdnilsen at openjdk.java.net Fri Jan 15 01:58:50 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Fri, 15 Jan 2021 01:58:50 GMT Subject: RFR: Scan remembered [v3] In-Reply-To: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> Message-ID: > Add support for scanning remembered set > > The code has support for two alternative implementations of the remembered set. The current remembered set implementation uses traditional card marking, where the post writer barrier for pointer write operations sets the mark for every overwritten card. > > A contemplated future remembered set implementation is represented in skeleton form within the shenandoahBufferWithSATBRememberedSet.hpp and shenandoahBufferWithSATBRememberedSet.inline.hpp files. The idea of this alternative remembered set implementation is that the existing SATB buffers will be augmented to additionally remember the address of each overwritten reference field. Subsequent processing of the SATB buffer contents by background GC threads will update the TBD remembered set representation. > > There are known bugs and performance improvements in the remembered set scanning implementation that have been addressed in certain Amazon-internal commits. These commits will be upstreamed at a later time after other commits not directly related to remembered set scanning are upstreamed. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Refinements requested by rkennke and zhengyu123 ------------- Changes: - all: https://git.openjdk.java.net/shenandoah/pull/12/files - new: https://git.openjdk.java.net/shenandoah/pull/12/files/8462a729..f4ae2f06 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=12&range=02 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=12&range=01-02 Stats: 25 lines in 5 files changed: 1 ins; 14 del; 10 mod Patch: https://git.openjdk.java.net/shenandoah/pull/12.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/12/head:pull/12 PR: https://git.openjdk.java.net/shenandoah/pull/12 From jwilhelm at openjdk.java.net Fri Jan 15 02:25:16 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Fri, 15 Jan 2021 02:25:16 GMT Subject: RFR: Merge jdk16 Message-ID: Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8253505: JFR: onFlush invoked out of order with a sorted event stream - 8255120: C2: assert(outer->outcnt() >= phis + 2 && outer->outcnt() <= phis + 2 + stores + 1) failed: only phis The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2087&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2087&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/2087/files Stats: 119 lines in 11 files changed: 43 ins; 40 del; 36 mod Patch: https://git.openjdk.java.net/jdk/pull/2087.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2087/head:pull/2087 PR: https://git.openjdk.java.net/jdk/pull/2087 From jwilhelm at openjdk.java.net Fri Jan 15 03:14:01 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Fri, 15 Jan 2021 03:14:01 GMT Subject: Integrated: Merge jdk16 In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 02:19:46 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: d701babb Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/d701babb Stats: 119 lines in 11 files changed: 43 ins; 40 del; 36 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/2087 From gnu.andrew at redhat.com Fri Jan 15 04:13:07 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 15 Jan 2021 04:13:07 +0000 Subject: [RFR] [8u] 8u282-b07 Upstream Sync Message-ID: <20210115041307.GA415880@rincewind> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b07/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b07/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b07/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b07/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b07/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b07/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b07/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b07/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b07/root/merge.changeset Changes in aarch64-shenandoah-jdk8u282-b07: - JDK-8225072: Add LuxTrust certificate that is expiring in March 2021 to list of allowed but expired certs - JDK-8239105: Add exception for expiring Digicert root certificates to VerifyCACerts test - JDK-8258630: Add expiry exception for QuoVadis root certificate Main issues of note: None, clean merge (no HotSpot changes). diffstat for root b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for corba b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxp b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxws b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for langtools b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for nashorn b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jdk b/.hgtags | 1 + b/test/sun/security/lib/cacerts/VerifyCACerts.java | 9 +++++++++ 2 files changed, 10 insertions(+) diffstat for hotspot b/.hgtags | 1 + 1 file changed, 1 insertion(+) Test only changes so builds are irrelevant. Ok to push? Thanks, -- Andrew :) 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 Fri Jan 15 12:49:20 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 15 Jan 2021 12:49:20 GMT Subject: RFR: Scan remembered [v3] In-Reply-To: References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> Message-ID: On Fri, 15 Jan 2021 01:15:24 GMT, Kelvin Nilsen wrote: >> src/hotspot/share/gc/shenandoah/shenandoahBufferWithSATBRememberedSet.hpp line 61: >> >>> 59: // existing SATB pre-write barrier to maintain remembered set information rather than using unconditional direct card marking in >>> 60: // a post-write barrier. >>> 61: class ShenandoahBufferWithSATBRememberedSet: public CHeapObj { >> >> So, if I understand correctly, you intend to piggy-back the field-address onto the SATB queue, is that right? It would mean that we need to double the size of the items in the buffer. And it would also mean that SATB needs to be turned on all the time, not just during marking. Is that correct? If that is so, I wonder if it may be better to do like G1 does and use a separate queue and barrier for this? It looks to me that it is doing exactly what we need here. > > As discussed in email messages exchanged on shenandoah-dev at openjdk.java.net, there are potential synergies between the SATB-based remembered set implementation and the existing SATB pre-write barrier. Especially if the default Shenandoah configuration chooses not to use SATB barrier, that increases the appeal of borrowing the G1 barrier implementation. If we were to choose the I-U barrier as default, that would still be possible/interesting to piggy-back the card-marking on. The I-U barrier is very similar to the SATB-barrier: it is also employed at reference-stores, and it also uses a reference-queue, pretty much like SATB. The only difference (barrier-side) is that, instead of enqueuing the previous value of a field before the store, it enqueues the *new* value, about to be stored (or even already-stored when done as post-barrier, it doesn't really matter). ------------- PR: https://git.openjdk.java.net/shenandoah/pull/12 From rkennke at openjdk.java.net Fri Jan 15 12:53:25 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 15 Jan 2021 12:53:25 GMT Subject: RFR: Scan remembered [v3] In-Reply-To: References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> Message-ID: On Fri, 15 Jan 2021 01:58:50 GMT, Kelvin Nilsen wrote: >> Add support for scanning remembered set >> >> The code has support for two alternative implementations of the remembered set. The current remembered set implementation uses traditional card marking, where the post writer barrier for pointer write operations sets the mark for every overwritten card. >> >> A contemplated future remembered set implementation is represented in skeleton form within the shenandoahBufferWithSATBRememberedSet.hpp and shenandoahBufferWithSATBRememberedSet.inline.hpp files. The idea of this alternative remembered set implementation is that the existing SATB buffers will be augmented to additionally remember the address of each overwritten reference field. Subsequent processing of the SATB buffer contents by background GC threads will update the TBD remembered set representation. >> >> There are known bugs and performance improvements in the remembered set scanning implementation that have been addressed in certain Amazon-internal commits. These commits will be upstreamed at a later time after other commits not directly related to remembered set scanning are upstreamed. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > Refinements requested by rkennke and zhengyu123 Looks good to me now. ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/shenandoah/pull/12 From zgu at openjdk.java.net Fri Jan 15 13:35:23 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 15 Jan 2021 13:35:23 GMT Subject: RFR: Scan remembered [v3] In-Reply-To: References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> Message-ID: <2iyHPq-5zZFgxdoeTVci6oW5RElK24QZrA4q2zVRFhE=.e9443c48-752b-41d3-8449-8249aa26f6a5@github.com> On Fri, 15 Jan 2021 01:58:50 GMT, Kelvin Nilsen wrote: >> Add support for scanning remembered set >> >> The code has support for two alternative implementations of the remembered set. The current remembered set implementation uses traditional card marking, where the post writer barrier for pointer write operations sets the mark for every overwritten card. >> >> A contemplated future remembered set implementation is represented in skeleton form within the shenandoahBufferWithSATBRememberedSet.hpp and shenandoahBufferWithSATBRememberedSet.inline.hpp files. The idea of this alternative remembered set implementation is that the existing SATB buffers will be augmented to additionally remember the address of each overwritten reference field. Subsequent processing of the SATB buffer contents by background GC threads will update the TBD remembered set representation. >> >> There are known bugs and performance improvements in the remembered set scanning implementation that have been addressed in certain Amazon-internal commits. These commits will be upstreamed at a later time after other commits not directly related to remembered set scanning are upstreamed. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > Refinements requested by rkennke and zhengyu123 Marked as reviewed by zgu (Reviewer). ------------- PR: https://git.openjdk.java.net/shenandoah/pull/12 From kdnilsen at openjdk.java.net Fri Jan 15 16:54:23 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Fri, 15 Jan 2021 16:54:23 GMT Subject: RFR: Scan remembered [v3] In-Reply-To: References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> Message-ID: On Fri, 15 Jan 2021 12:46:30 GMT, Roman Kennke wrote: >> As discussed in email messages exchanged on shenandoah-dev at openjdk.java.net, there are potential synergies between the SATB-based remembered set implementation and the existing SATB pre-write barrier. Especially if the default Shenandoah configuration chooses not to use SATB barrier, that increases the appeal of borrowing the G1 barrier implementation. > > If we were to choose the I-U barrier as default, that would still be possible/interesting to piggy-back the card-marking on. The I-U barrier is very similar to the SATB-barrier: it is also employed at reference-stores, and it also uses a reference-queue, pretty much like SATB. The only difference (barrier-side) is that, instead of enqueuing the previous value of a field before the store, it enqueues the *new* value, about to be stored (or even already-stored when done as post-barrier, it doesn't really matter). Thanks for the email clarifying how the I-U barrier works. I hadn't yet studied that. I agree that we could also piggy-back card marking on that barrier. I will explore further. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/12 From kdnilsen at openjdk.java.net Fri Jan 15 18:13:26 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Fri, 15 Jan 2021 18:13:26 GMT Subject: Integrated: Scan remembered In-Reply-To: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> References: <9hPFJ00yKZEKOhxsVDOO9THb-TXffj2sdqjU_OgXgb8=.0c70e91f-ff8b-4a66-9a88-6dd2b6625ca9@github.com> Message-ID: On Fri, 8 Jan 2021 17:56:02 GMT, Kelvin Nilsen wrote: > Add support for scanning remembered set > > The code has support for two alternative implementations of the remembered set. The current remembered set implementation uses traditional card marking, where the post writer barrier for pointer write operations sets the mark for every overwritten card. > > A contemplated future remembered set implementation is represented in skeleton form within the shenandoahBufferWithSATBRememberedSet.hpp and shenandoahBufferWithSATBRememberedSet.inline.hpp files. The idea of this alternative remembered set implementation is that the existing SATB buffers will be augmented to additionally remember the address of each overwritten reference field. Subsequent processing of the SATB buffer contents by background GC threads will update the TBD remembered set representation. > > There are known bugs and performance improvements in the remembered set scanning implementation that have been addressed in certain Amazon-internal commits. These commits will be upstreamed at a later time after other commits not directly related to remembered set scanning are upstreamed. This pull request has now been integrated. Changeset: 8a38a9ed Author: Kelvin Nilsen Committer: Roman Kennke URL: https://git.openjdk.java.net/shenandoah/commit/8a38a9ed Stats: 1552 lines in 9 files changed: 1526 ins; 11 del; 15 mod Scan remembered Reviewed-by: rkennke, zgu ------------- PR: https://git.openjdk.java.net/shenandoah/pull/12 From rkennke at openjdk.java.net Fri Jan 15 18:25:15 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 15 Jan 2021 18:25:15 GMT Subject: RFR: 8259849: Shenandoah: Rename store-val to IU-barrier Message-ID: We named the IU barriers StoreValEnqueueBarrier and various similar variations of this. Instead of naming it after how it's implemented, we should name it after its purpose: support IU-marking. It also looks confusing to have enqueue_barrier() and similar stuff, where no barrier is actually enqueued. The renaming was 100% mechanical. Testing: - [ ] hotspot_gc_shenandoah (x86_64, x86_32, aarch64) ------------- Commit messages: - 8259849: Shenandoah: Rename store-val to IU-barrier Changes: https://git.openjdk.java.net/jdk/pull/2104/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2104&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259849 Stats: 108 lines in 23 files changed: 0 ins; 5 del; 103 mod Patch: https://git.openjdk.java.net/jdk/pull/2104.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2104/head:pull/2104 PR: https://git.openjdk.java.net/jdk/pull/2104 From zgu at openjdk.java.net Fri Jan 15 18:54:07 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 15 Jan 2021 18:54:07 GMT Subject: RFR: 8259849: Shenandoah: Rename store-val to IU-barrier In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 18:19:09 GMT, Roman Kennke wrote: > We named the IU barriers StoreValEnqueueBarrier and various similar variations of this. Instead of naming it after how it's implemented, we should name it after its purpose: support IU-marking. It also looks confusing to have enqueue_barrier() and similar stuff, where no barrier is actually enqueued. > > The renaming was 100% mechanical. > > Testing: > - [ ] hotspot_gc_shenandoah (x86_64, x86_32, aarch64) Some file's copyright year need to be updated. Otherwise, looks good. ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2104 From rkennke at openjdk.java.net Fri Jan 15 23:10:26 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 15 Jan 2021 23:10:26 GMT Subject: RFR: 8259849: Shenandoah: Rename store-val to IU-barrier [v2] In-Reply-To: References: Message-ID: > We named the IU barriers StoreValEnqueueBarrier and various similar variations of this. Instead of naming it after how it's implemented, we should name it after its purpose: support IU-marking. It also looks confusing to have enqueue_barrier() and similar stuff, where no barrier is actually enqueued. > > The renaming was 100% mechanical. > > Testing: > - [ ] hotspot_gc_shenandoah (x86_64, x86_32, aarch64) Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Update copyright years in modified files ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2104/files - new: https://git.openjdk.java.net/jdk/pull/2104/files/2d2b0130..3804e64e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2104&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2104&range=00-01 Stats: 20 lines in 20 files changed: 0 ins; 0 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/2104.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2104/head:pull/2104 PR: https://git.openjdk.java.net/jdk/pull/2104 From kbarrett at openjdk.java.net Sat Jan 16 15:40:31 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 16 Jan 2021 15:40:31 GMT Subject: RFR: 8256814: WeakProcessorPhases may be redundant [v2] In-Reply-To: References: Message-ID: > Please review this change which eliminates the WeakProcessorPhase class. > > The OopStorageSet class is changed to provide scoped enums for the different > categories: StrongId, WeakId, and Id (for the union of strong and weak). > An accessor is provided for obtaining the storage corresponding to a > category value. > > Various other enumerator ranges, array sizes and indices, and iterations are > derived directly from the corresponding OopStorageSet category's enum range. > > Iteration over a category of enumerators can be done via EnumIterator. The > iteration over storage objects makes use of that enum iteration, rather than > having a bespoke implementation. Some use-cases need iteration of the > enumerators, with storage lookup from the enumerator; other use-cases just > need the storage objects. > > Testing: > mach5 tier1-6 > Local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into wpp4 - stefank review - Remove WeakProcessorPhase, adding scoped enum categories to OopStorageSet. ------------- Changes: https://git.openjdk.java.net/jdk/pull/1862/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1862&range=01 Stats: 1042 lines in 25 files changed: 400 ins; 465 del; 177 mod Patch: https://git.openjdk.java.net/jdk/pull/1862.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1862/head:pull/1862 PR: https://git.openjdk.java.net/jdk/pull/1862 From kim.barrett at oracle.com Sat Jan 16 15:42:44 2021 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 16 Jan 2021 10:42:44 -0500 Subject: RFR: 8256814: WeakProcessorPhases may be redundant In-Reply-To: References: Message-ID: <33C0F891-C26A-4B41-B85A-84627676071D@oracle.com> > On Jan 12, 2021, at 5:12 AM, Stefan Karlsson wrote: > > On Tue, 22 Dec 2020 04:59:28 GMT, Kim Barrett wrote: > >> Please review this change which eliminates the WeakProcessorPhase class. >> >> The OopStorageSet class is changed to provide scoped enums for the different >> categories: StrongId, WeakId, and Id (for the union of strong and weak). >> An accessor is provided for obtaining the storage corresponding to a >> category value. >> >> Various other enumerator ranges, array sizes and indices, and iterations are >> derived directly from the corresponding OopStorageSet category's enum range. >> >> Iteration over a category of enumerators can be done via EnumIterator. The >> iteration over storage objects makes use of that enum iteration, rather than >> having a bespoke implementation. Some use-cases need iteration of the >> enumerators, with storage lookup from the enumerator; other use-cases just >> need the storage objects. >> >> Testing: >> mach5 tier1-6 >> Local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC > > I think this looks good. I have a few comments that I would like to get addressed, but they are not blockers if you want to proceed with what you have. Thanks. > src/hotspot/share/gc/shared/oopStorageSetParState.hpp line 35: > >> 33: >> 34: // Base class for OopStorageSet{Strong,Weak}ParState. >> 35: template > > While reviewing this, it was not immediately obvious what T represent. EnumRange uses the name StorageId, maybe use the same here? T -> StorageId -- done. > src/hotspot/share/gc/shared/oopStorageSetParState.hpp line 52: > >> 50: >> 51: NONCOPYABLE(OopStorageSetParState); >> 52: }; > > We tend to put the member variables at the top of classes. I don't think ParState needs to be public, and this could be changed to: > [?] Having a public function whose type signature involves identifiers that can't be used by clients, particularly for the return type, is problematic. Personally, I intensely dislike the typical HotSpot ordering, but go along anyway if there's not a direct reason not to, as there is here. (The HotSpot ordering also happens to be contrary to every style guide I've ever seen discuss the subject, and those style guides give good reasons that are the basis of my dislike.) Options are (1) drop the type alias and write out the type, (2) have multiple public sections, (3) put the public stuff first. I prefer (3). Though I went with (2) in weakProcessorTimes.hpp, to reduce the code churn for this PR. > src/hotspot/share/gc/shared/oopStorageSetParState.hpp line 58: > >> 56: class OopStorageSetStrongParState >> 57: : public OopStorageSetParState >> 58: { > > We usually keep the `{` on the same line. We also usually put the base class on the same line as the class, but that made the lines longer than I like, hence the line break there. Having the open brace at the end of the base class line then makes the distinction between the base class part and the members more subtle than I liked; I think the brace placement I used helps with that. (All this is a long-winded way of saying that the formatting here is intentional, attempting to make the code easier to parse by eye.) > src/hotspot/share/gc/shared/oopStorageSetParState.hpp line 68: > >> 66: class OopStorageSetWeakParState >> 67: : public OopStorageSetParState >> 68: { > > Same comment as above. > > src/hotspot/share/gc/shared/oopStorageSetParState.inline.hpp line 36: > >> 34: >> 35: template >> 36: template > > Other places in the file uses `template <` so the usage of `template<` makes the code inconsistent. Yeah, sorry, I try to be consistent with nearby code but failed here; fixed. FWIW, HotSpot uses both, and there doesn't seem to be a consensus in the wider C++ community. The C++ Standard uses both! My default has always been no-space, and having a space there bugs me a little, but not enough to argue over. > src/hotspot/share/gc/shared/weakProcessorTimes.hpp line 37: > >> 35: class WeakProcessorTimes { >> 36: public: >> 37: using StorageId = OopStorageSet::WeakId; > > Could be private. Here too I think public functions whose type signatures involve identifiers that can't be used by clients is problematic. But I renamed it from StorageId to WeakId; looking at it again, the more generic name seems counterproductive here. > test/hotspot/gtest/gc/shared/test_oopStorageSet.cpp line 48: > >> 46: >> 47: template >> 48: static void check_iterator(OopStorageSet::Iterator it, > > All the functions you changed are named `_iterator` and tested OopStorageSet::Iterator. Now the name is the same, but instead they test the Range facility. I think these functions should be renamed. Alternatively, we keep the tests for the OopStorageSet::Iterator and create a new set for the Range? What's being tested is iteration, so "iterator" => "iteration? throughout seems better. > Marked as reviewed by stefank (Reviewer). Thanks for reviewing. > PR: https://git.openjdk.java.net/jdk/pull/1862 From kbarrett at openjdk.java.net Sun Jan 17 13:21:57 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 17 Jan 2021 13:21:57 GMT Subject: RFR: 8258742: Move PtrQueue reset to PtrQueueSet subclasses Message-ID: Please remove this change to the PtrQueue hierarchy, changing queue reset from an intrinsic operation of the queue to an operation the qset performs on a queue. This is another piece of the refactoring being done under JDK-8258251, separated out for easier review. After the refactoring of queue reset, PtrQueue::is_empty and PtrQueue::size are no longer used, so are removed. Further, PtrQueue::{set_}index_in_bytes are removed, directly using _index instead. A less obvious part of the change is in the G1 remark task and Shenandoah final marking task. The threads walk performed by these no longer directly processes the partial per-thread SATB buffers. Instead they just flush the queues for later completed buffer processing. Testing: mach5 tier1 local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC ------------- Commit messages: - update shenandoah - remove pq index_in_bytes - remove pq size - remove pq is_empty - move reset Changes: https://git.openjdk.java.net/jdk/pull/2115/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2115&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258742 Stats: 89 lines in 9 files changed: 17 ins; 45 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/2115.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2115/head:pull/2115 PR: https://git.openjdk.java.net/jdk/pull/2115 From shade at openjdk.java.net Mon Jan 18 10:09:54 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 18 Jan 2021 10:09:54 GMT Subject: RFR: 8259849: Shenandoah: Rename store-val to IU-barrier [v2] In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 23:10:26 GMT, Roman Kennke wrote: >> We named the IU barriers StoreValEnqueueBarrier and various similar variations of this. Instead of naming it after how it's implemented, we should name it after its purpose: support IU-marking. It also looks confusing to have enqueue_barrier() and similar stuff, where no barrier is actually enqueued. >> >> The renaming was 100% mechanical. >> >> Testing: >> - [ ] hotspot_gc_shenandoah (x86_64, x86_32, aarch64) > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright years in modified files This makes sense. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2104 From shade at openjdk.java.net Mon Jan 18 10:09:55 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 18 Jan 2021 10:09:55 GMT Subject: RFR: 8259849: Shenandoah: Rename store-val to IU-barrier [v2] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 10:05:14 GMT, Aleksey Shipilev wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright years in modified files > > This makes sense. ...except that GHA report these two tests have failed: gc/shenandoah/options/TestWrongBarrierDisable.java gc/shenandoah/options/TestWrongBarrierEnable.java ------------- PR: https://git.openjdk.java.net/jdk/pull/2104 From rkennke at openjdk.java.net Mon Jan 18 10:22:05 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 18 Jan 2021 10:22:05 GMT Subject: RFR: 8259849: Shenandoah: Rename store-val to IU-barrier [v3] In-Reply-To: References: Message-ID: <-V_pN8Z-yBefpevDtyLy_A77-YNvlGXJuiXKD3_9f2s=.30835087-e001-4ffe-8467-afa69c1cf347@github.com> > We named the IU barriers StoreValEnqueueBarrier and various similar variations of this. Instead of naming it after how it's implemented, we should name it after its purpose: support IU-marking. It also looks confusing to have enqueue_barrier() and similar stuff, where no barrier is actually enqueued. > > The renaming was 100% mechanical. > > Testing: > - [ ] hotspot_gc_shenandoah (x86_64, x86_32, aarch64) Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Change to I-U barrier name in tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2104/files - new: https://git.openjdk.java.net/jdk/pull/2104/files/3804e64e..31810029 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2104&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2104&range=01-02 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2104.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2104/head:pull/2104 PR: https://git.openjdk.java.net/jdk/pull/2104 From shade at redhat.com Mon Jan 18 10:32:28 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 Jan 2021 11:32:28 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u282-b07 Upstream Sync In-Reply-To: <20210115041307.GA415880@rincewind> References: <20210115041307.GA415880@rincewind> Message-ID: <71fe7844-68c6-0ccc-5247-f5d4c10ba10d@redhat.com> On 1/15/21 5:13 AM, Andrew Hughes wrote: > Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b07/ > > Merge changesets: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b07/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b07/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b07/jaxws/merge.changeset Look trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b07/jdk/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b07/hotspot/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b07/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b07/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b07/root/merge.changeset Look trivially good. > Ok to push? Yes. -- Thanks, -Aleksey From tschatzl at openjdk.java.net Mon Jan 18 10:34:51 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 18 Jan 2021 10:34:51 GMT Subject: RFR: 8256814: WeakProcessorPhases may be redundant [v2] In-Reply-To: References: Message-ID: On Sat, 16 Jan 2021 15:40:31 GMT, Kim Barrett wrote: >> Please review this change which eliminates the WeakProcessorPhase class. >> >> The OopStorageSet class is changed to provide scoped enums for the different >> categories: StrongId, WeakId, and Id (for the union of strong and weak). >> An accessor is provided for obtaining the storage corresponding to a >> category value. >> >> Various other enumerator ranges, array sizes and indices, and iterations are >> derived directly from the corresponding OopStorageSet category's enum range. >> >> Iteration over a category of enumerators can be done via EnumIterator. The >> iteration over storage objects makes use of that enum iteration, rather than >> having a bespoke implementation. Some use-cases need iteration of the >> enumerators, with storage lookup from the enumerator; other use-cases just >> need the storage objects. >> >> Testing: >> mach5 tier1-6 >> Local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC > > Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into wpp4 > - stefank review > - Remove WeakProcessorPhase, adding scoped enum categories to OopStorageSet. Marked as reviewed by tschatzl (Reviewer). src/hotspot/share/gc/shared/oopStorageSet.cpp line 2: > 1: /* > 2: * Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved. It's 2021 by now, I suggest to update these before pushing. ------------- PR: https://git.openjdk.java.net/jdk/pull/1862 From tschatzl at openjdk.java.net Mon Jan 18 10:37:46 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 18 Jan 2021 10:37:46 GMT Subject: RFR: 8258742: Move PtrQueue reset to PtrQueueSet subclasses In-Reply-To: References: Message-ID: <1dgRRDTcWGLGFijLRvA01DMsmGoQMoFZM8-1Z5VrWQ4=.96f80cf3-136b-4a86-bf9e-f9db626f3979@github.com> On Sun, 17 Jan 2021 13:17:20 GMT, Kim Barrett wrote: > Please remove this change to the PtrQueue hierarchy, changing queue reset > from an intrinsic operation of the queue to an operation the qset performs > on a queue. This is another piece of the refactoring being done under > JDK-8258251, separated out for easier review. > > After the refactoring of queue reset, PtrQueue::is_empty and PtrQueue::size > are no longer used, so are removed. Further, PtrQueue::{set_}index_in_bytes > are removed, directly using _index instead. > > A less obvious part of the change is in the G1 remark task and Shenandoah > final marking task. The threads walk performed by these no longer directly > processes the partial per-thread SATB buffers. Instead they just flush the > queues for later completed buffer processing. > > Testing: > mach5 tier1 > local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2115 From kim.barrett at oracle.com Mon Jan 18 10:41:38 2021 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 18 Jan 2021 05:41:38 -0500 Subject: RFR: 8256814: WeakProcessorPhases may be redundant In-Reply-To: <33C0F891-C26A-4B41-B85A-84627676071D@oracle.com> References: <33C0F891-C26A-4B41-B85A-84627676071D@oracle.com> Message-ID: <39C4F5B9-FA6C-4E5C-95A3-2A1F7C1299B3@oracle.com> > On Jan 16, 2021, at 10:42 AM, Kim Barrett wrote: > >> On Jan 12, 2021, at 5:12 AM, Stefan Karlsson wrote: >> src/hotspot/share/gc/shared/weakProcessorTimes.hpp line 37: >> >>> 35: class WeakProcessorTimes { >>> 36: public: >>> 37: using StorageId = OopStorageSet::WeakId; >> >> Could be private. > > Here too I think public functions whose type signatures involve identifiers > that can't be used by clients is problematic. But I renamed it from > StorageId to WeakId; looking at it again, the more generic name seems > counterproductive here. After thinking about this some more, I?m going to see what it looks like to just eliminate the type alias entirely. From rkennke at openjdk.java.net Mon Jan 18 13:34:49 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 18 Jan 2021 13:34:49 GMT Subject: RFR: 8259849: Shenandoah: Rename store-val to IU-barrier [v2] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 10:06:32 GMT, Aleksey Shipilev wrote: > ...except that GHA report these two tests have failed: > gc/shenandoah/options/TestWrongBarrierDisable.java > gc/shenandoah/options/TestWrongBarrierEnable.java Right. Those should be fixed now. Only remaining GHA failure is Windows: configure: error: Could not find a C compiler. Do you know what's up there? ------------- PR: https://git.openjdk.java.net/jdk/pull/2104 From shade at openjdk.java.net Mon Jan 18 13:38:47 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 18 Jan 2021 13:38:47 GMT Subject: RFR: 8259849: Shenandoah: Rename store-val to IU-barrier [v2] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 13:31:58 GMT, Roman Kennke wrote: > Right. Those should be fixed now. Only remaining GHA failure is Windows: > > configure: error: Could not find a C compiler. > Do you know what's up there? Known issue: https://bugs.openjdk.java.net/browse/JDK-8259679 ------------- PR: https://git.openjdk.java.net/jdk/pull/2104 From kbarrett at openjdk.java.net Mon Jan 18 15:08:12 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 18 Jan 2021 15:08:12 GMT Subject: RFR: 8256814: WeakProcessorPhases may be redundant [v3] In-Reply-To: References: Message-ID: > Please review this change which eliminates the WeakProcessorPhase class. > > The OopStorageSet class is changed to provide scoped enums for the different > categories: StrongId, WeakId, and Id (for the union of strong and weak). > An accessor is provided for obtaining the storage corresponding to a > category value. > > Various other enumerator ranges, array sizes and indices, and iterations are > derived directly from the corresponding OopStorageSet category's enum range. > > Iteration over a category of enumerators can be done via EnumIterator. The > iteration over storage objects makes use of that enum iteration, rather than > having a bespoke implementation. Some use-cases need iteration of the > enumerators, with storage lookup from the enumerator; other use-cases just > need the storage objects. > > Testing: > mach5 tier1-6 > Local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: - update copyrights - remove type aliases for OopStorageSet::WeakId ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1862/files - new: https://git.openjdk.java.net/jdk/pull/1862/files/3a4d5b78..ebe50e35 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1862&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1862&range=01-02 Stats: 48 lines in 17 files changed: 6 ins; 8 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/1862.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1862/head:pull/1862 PR: https://git.openjdk.java.net/jdk/pull/1862 From kim.barrett at oracle.com Mon Jan 18 15:10:22 2021 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 18 Jan 2021 10:10:22 -0500 Subject: RFR: 8256814: WeakProcessorPhases may be redundant In-Reply-To: <39C4F5B9-FA6C-4E5C-95A3-2A1F7C1299B3@oracle.com> References: <33C0F891-C26A-4B41-B85A-84627676071D@oracle.com> <39C4F5B9-FA6C-4E5C-95A3-2A1F7C1299B3@oracle.com> Message-ID: <9D910C33-7007-46B3-8638-93CC65E267FC@oracle.com> > On Jan 18, 2021, at 5:41 AM, Kim Barrett wrote: > >> On Jan 16, 2021, at 10:42 AM, Kim Barrett wrote: >> >>> On Jan 12, 2021, at 5:12 AM, Stefan Karlsson wrote: >>> src/hotspot/share/gc/shared/weakProcessorTimes.hpp line 37: >>> >>>> 35: class WeakProcessorTimes { >>>> 36: public: >>>> 37: using StorageId = OopStorageSet::WeakId; >>> >>> Could be private. >> >> Here too I think public functions whose type signatures involve identifiers >> that can't be used by clients is problematic. But I renamed it from >> StorageId to WeakId; looking at it again, the more generic name seems >> counterproductive here. > > After thinking about this some more, I?m going to see what it looks like to just > eliminate the type alias entirely. Done. The type alias didn?t really add much, just shortening some a few uses and signatures, not really enough to justify adding it. I also updated the copyrights for 2021. From rkennke at openjdk.java.net Mon Jan 18 15:32:54 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 18 Jan 2021 15:32:54 GMT Subject: Integrated: 8259849: Shenandoah: Rename store-val to IU-barrier In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 18:19:09 GMT, Roman Kennke wrote: > We named the IU barriers StoreValEnqueueBarrier and various similar variations of this. Instead of naming it after how it's implemented, we should name it after its purpose: support IU-marking. It also looks confusing to have enqueue_barrier() and similar stuff, where no barrier is actually enqueued. > > The renaming was 100% mechanical. > > Testing: > - [x] hotspot_gc_shenandoah (x86_64, x86_32, aarch64) This pull request has now been integrated. Changeset: e60c9926 Author: Roman Kennke URL: https://git.openjdk.java.net/jdk/commit/e60c9926 Stats: 131 lines in 26 files changed: 0 ins; 5 del; 126 mod 8259849: Shenandoah: Rename store-val to IU-barrier Reviewed-by: zgu, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/2104 From rkennke at openjdk.java.net Mon Jan 18 18:23:47 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 18 Jan 2021 18:23:47 GMT Subject: RFR: 8256814: WeakProcessorPhases may be redundant [v3] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 15:08:12 GMT, Kim Barrett wrote: >> Please review this change which eliminates the WeakProcessorPhase class. >> >> The OopStorageSet class is changed to provide scoped enums for the different >> categories: StrongId, WeakId, and Id (for the union of strong and weak). >> An accessor is provided for obtaining the storage corresponding to a >> category value. >> >> Various other enumerator ranges, array sizes and indices, and iterations are >> derived directly from the corresponding OopStorageSet category's enum range. >> >> Iteration over a category of enumerators can be done via EnumIterator. The >> iteration over storage objects makes use of that enum iteration, rather than >> having a bespoke implementation. Some use-cases need iteration of the >> enumerators, with storage lookup from the enumerator; other use-cases just >> need the storage objects. >> >> Testing: >> mach5 tier1-6 >> Local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC > > Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: > > - update copyrights > - remove type aliases for OopStorageSet::WeakId Changes look good to me! I also ran some tests with Shenandoah and they look good too! Thanks! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1862 From rkennke at openjdk.java.net Mon Jan 18 20:32:51 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 18 Jan 2021 20:32:51 GMT Subject: RFR: 8255765: Shenandoah: Isolate concurrent, degenerated and full GC In-Reply-To: <9sUK197ZPOSEPLEDl8zKSqby-KMi9FryXnoctOdWmMc=.7b678df1-1c51-4bbf-b1a3-d8a8167a927d@github.com> References: <9sUK197ZPOSEPLEDl8zKSqby-KMi9FryXnoctOdWmMc=.7b678df1-1c51-4bbf-b1a3-d8a8167a927d@github.com> Message-ID: On Wed, 6 Jan 2021 16:45:03 GMT, Zhengyu Gu wrote: > The purpose of this patch is to isolate concurrent, degenerated and full gc implementation, so that, makes each GC implementation more straightforward and clean, and improves readability. > > Current implementation emphasis code sharing, e.g. degenerated GC reuses concurrent GC's ops. It was not a problem in the beginning, when they actually behave similarly. Since concurrent GC moved root processing into concurrent phases, code started to diverge, we started to put bandages to make the shared ops work for both concurrent and degenerated GC, that made code hard to read and error prone. > > The patch breaks up GCs into 3 (mainly just concurrent and degenerated GC, as full GC already standalone) easy to identify and understand classes (ShenandoahConcurrentGC, ShenandoahDegeneratedGC and ShenandoahMarkCompactGC), subclasses of ShenandoahGC class. > > The three GCs still keep vmop/entry/op paradigm, but encapsulate GC control flow inside their own classes, as ShenandoahMarkCompact GC already does. So that, concurrent and degenerated GC no longer share ops and op implementations no longer need to consider other GC modes, which results in simplifying implementation and improving readability. Code sharing is achieved via helper methods provided by ShenandoahHeap. > > Test: > - [x] hotspot_gc_shenandoah > - [x] nightly tests Nice! I really like how that moves some burden out from ShHeap (and ShControlThread) to more apprppriate places. Just the following two remarks. src/hotspot/share/gc/shenandoah/shenandoahCollectorPolicy.cpp line 45: > 43: _cycle_counter(0) { > 44: > 45: Copy::zero_to_bytes(_degen_points, sizeof(size_t) * ShenandoahGC::_DEGENERATED_LIMIT); I wonder if those statistics all belong into ShenandoahDegenGC now? Might be worth considering as a follow-up. src/hotspot/share/gc/shenandoah/shenandoahCollectorPolicy.hpp line 30: > 28: #include "gc/shared/gcTrace.hpp" > 29: #include "gc/shenandoah/shenandoahGC.hpp" > 30: #include "gc/shenandoah/shenandoahSharedVariables.hpp" What's that include for shenandoahSharedVariables.hpp needed for? ------------- PR: https://git.openjdk.java.net/jdk/pull/1964 From rkennke at openjdk.java.net Mon Jan 18 20:32:51 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 18 Jan 2021 20:32:51 GMT Subject: RFR: 8255765: Shenandoah: Isolate concurrent, degenerated and full GC In-Reply-To: References: <9sUK197ZPOSEPLEDl8zKSqby-KMi9FryXnoctOdWmMc=.7b678df1-1c51-4bbf-b1a3-d8a8167a927d@github.com> Message-ID: On Mon, 18 Jan 2021 20:28:14 GMT, Roman Kennke wrote: >> The purpose of this patch is to isolate concurrent, degenerated and full gc implementation, so that, makes each GC implementation more straightforward and clean, and improves readability. >> >> Current implementation emphasis code sharing, e.g. degenerated GC reuses concurrent GC's ops. It was not a problem in the beginning, when they actually behave similarly. Since concurrent GC moved root processing into concurrent phases, code started to diverge, we started to put bandages to make the shared ops work for both concurrent and degenerated GC, that made code hard to read and error prone. >> >> The patch breaks up GCs into 3 (mainly just concurrent and degenerated GC, as full GC already standalone) easy to identify and understand classes (ShenandoahConcurrentGC, ShenandoahDegeneratedGC and ShenandoahMarkCompactGC), subclasses of ShenandoahGC class. >> >> The three GCs still keep vmop/entry/op paradigm, but encapsulate GC control flow inside their own classes, as ShenandoahMarkCompact GC already does. So that, concurrent and degenerated GC no longer share ops and op implementations no longer need to consider other GC modes, which results in simplifying implementation and improving readability. Code sharing is achieved via helper methods provided by ShenandoahHeap. >> >> Test: >> - [x] hotspot_gc_shenandoah >> - [x] nightly tests > > Nice! I really like how that moves some burden out from ShHeap (and ShControlThread) to more apprppriate places. Just the following two remarks. @shipilev should also look at this. ------------- PR: https://git.openjdk.java.net/jdk/pull/1964 From shade at openjdk.java.net Tue Jan 19 10:36:03 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 19 Jan 2021 10:36:03 GMT Subject: RFR: 8259962: Shenandoah: task queue statistics is inconsistent after JDK-8255019 Message-ID: I believe `ShenandoahSTWMark` misses the TQ stats reset after the takeover from concurrent cycle. See the stack trace and events info in the bug. Additional testing: - [x] Linux x86_64, failing tests now pass - [x] Linux x86_64 `hotspot_gc_shenandoah` - [ ] Linux x86_64 `tier1` with Shenandoah ------------- Commit messages: - 8259962: Shenandoah: task queue statistics is inconsistent after JDK-8255019 Changes: https://git.openjdk.java.net/jdk/pull/2141/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2141&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259962 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2141.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2141/head:pull/2141 PR: https://git.openjdk.java.net/jdk/pull/2141 From shade at openjdk.java.net Tue Jan 19 12:09:54 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 19 Jan 2021 12:09:54 GMT Subject: RFR: 8255765: Shenandoah: Isolate concurrent, degenerated and full GC In-Reply-To: <9sUK197ZPOSEPLEDl8zKSqby-KMi9FryXnoctOdWmMc=.7b678df1-1c51-4bbf-b1a3-d8a8167a927d@github.com> References: <9sUK197ZPOSEPLEDl8zKSqby-KMi9FryXnoctOdWmMc=.7b678df1-1c51-4bbf-b1a3-d8a8167a927d@github.com> Message-ID: On Wed, 6 Jan 2021 16:45:03 GMT, Zhengyu Gu wrote: > The purpose of this patch is to isolate concurrent, degenerated and full gc implementation, so that, makes each GC implementation more straightforward and clean, and improves readability. > > Current implementation emphasis code sharing, e.g. degenerated GC reuses concurrent GC's ops. It was not a problem in the beginning, when they actually behave similarly. Since concurrent GC moved root processing into concurrent phases, code started to diverge, we started to put bandages to make the shared ops work for both concurrent and degenerated GC, that made code hard to read and error prone. > > The patch breaks up GCs into 3 (mainly just concurrent and degenerated GC, as full GC already standalone) easy to identify and understand classes (ShenandoahConcurrentGC, ShenandoahDegeneratedGC and ShenandoahMarkCompactGC), subclasses of ShenandoahGC class. > > The three GCs still keep vmop/entry/op paradigm, but encapsulate GC control flow inside their own classes, as ShenandoahMarkCompact GC already does. So that, concurrent and degenerated GC no longer share ops and op implementations no longer need to consider other GC modes, which results in simplifying implementation and improving readability. Code sharing is achieved via helper methods provided by ShenandoahHeap. > > Test: > - [x] hotspot_gc_shenandoah > - [x] nightly tests Some minor nits from the initial review. Please make sure `tier1` and `tier2` with Shenandoah still pass. src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.hpp line 53: > 51: ShenandoahDegenPoint degen_point() const; > 52: > 53: // Cancel on going concurrent GC "ongoing"? src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp line 28: > 26: > 27: #include "gc/shared/collectorCounters.hpp" > 28: Do we really need these newlines? src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp line 44: > 42: #include "gc/shenandoah/shenandoahWorkerPolicy.hpp" > 43: #include "gc/shenandoah/shenandoahVMOperations.hpp" > 44: ...and this newline? src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.hpp line 54: > 52: // Prepare STW evacuation > 53: void op_prepare_evacuation(); > 54: // Empty comment. Actually, do we even need comments here? I.e. does `ShenandoahConcurrentGC` have them? src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.hpp line 25: > 23: */ > 24: > 25: #ifndef SHARE_GC_SHENANDOAH_SHENANDOAHDEGENDGC_HPP The include guard should match the file name, maybe? `SHARE_GC_SHENANDOAH_SHENANDOAHDEGENERATEDGC_HPP`? src/hotspot/share/gc/shenandoah/shenandoahGC.cpp line 28: > 26: > 27: #include "gc/shared/workgroup.hpp" > 28: Excess newlines? src/hotspot/share/gc/shenandoah/shenandoahGC.hpp line 43: > 41: * | | upgrade from degenerated GC | > 42: * Full GC---------------------------v---------------------------->| > 43: */ This diagram is confusing to me. ("normal" mode) ----> Concurrent GC ----> (finish) | | v ("passive" mode) ---> Degenerated GC ---> (finish) | | v Full GC --------> (finish) src/hotspot/share/gc/shenandoah/shenandoahGC.hpp line 32: > 30: > 31: /* > 32: * Base class of three Shenandoah GC modes Is it a "mode", though? There is `ShenandoahGCMode`, which means a different thing. Maybe "flavor"? src/hotspot/share/gc/shenandoah/shenandoahGC.hpp line 66: > 64: }; > 65: > 66: #endif No newline at the end of the file. src/hotspot/share/gc/shenandoah/shenandoahGC.hpp line 45: > 43: */ > 44: > 45: class ShenandoahHeap; Cannot see why this forward declaration is needed. src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 128: > 126: friend class ShenandoahConcurrentGC; > 127: friend class ShenandoahDegenGC; > 128: friend class ShenandoahMarkCompact; At some point, it would make sense to rename `ShenandoahMarkCompact` to `ShenandoahFullGC`? src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 369: > 367: > 368: public: > 369: void notify_gc_progress() { _progress_last_gc.set();} Align the closing brace with the next line? src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp line 196: > 194: > 195: if (!heap->unload_classes()) { > 196: _cld_roots.cld_do(&clds_cl, worker_id); This change seems unrelated? ------------- Changes requested by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1964 From zgu at openjdk.java.net Tue Jan 19 13:13:37 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 19 Jan 2021 13:13:37 GMT Subject: RFR: 8259962: Shenandoah: task queue statistics is inconsistent after JDK-8255019 In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 10:27:26 GMT, Aleksey Shipilev wrote: > I believe `ShenandoahSTWMark` misses the TQ stats reset after the takeover from concurrent cycle. See the stack trace and events info in the bug. > > Additional testing: > - [x] Linux x86_64, failing tests now pass > - [x] Linux x86_64 `hotspot_gc_shenandoah` > - [x] Linux x86_64 `tier1` with Shenandoah Thanks for catching this. Looks good. Concurrent mark resets qstats in ShenandoahConcurrentMark::mark_stw_roots(), so it should be fine. ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2141 From shade at openjdk.java.net Tue Jan 19 14:42:48 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 19 Jan 2021 14:42:48 GMT Subject: Integrated: 8259962: Shenandoah: task queue statistics is inconsistent after JDK-8255019 In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 10:27:26 GMT, Aleksey Shipilev wrote: > I believe `ShenandoahSTWMark` misses the TQ stats reset after the takeover from concurrent cycle. See the stack trace and events info in the bug. > > Additional testing: > - [x] Linux x86_64, failing tests now pass > - [x] Linux x86_64 `hotspot_gc_shenandoah` > - [x] Linux x86_64 `tier1` with Shenandoah This pull request has now been integrated. Changeset: c0e9c446 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/c0e9c446 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8259962: Shenandoah: task queue statistics is inconsistent after JDK-8255019 Reviewed-by: zgu ------------- PR: https://git.openjdk.java.net/jdk/pull/2141 From shade at openjdk.java.net Tue Jan 19 14:42:47 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 19 Jan 2021 14:42:47 GMT Subject: RFR: 8259962: Shenandoah: task queue statistics is inconsistent after JDK-8255019 In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 13:11:11 GMT, Zhengyu Gu wrote: >> I believe `ShenandoahSTWMark` misses the TQ stats reset after the takeover from concurrent cycle. See the stack trace and events info in the bug. >> >> Additional testing: >> - [x] Linux x86_64, failing tests now pass >> - [x] Linux x86_64 `hotspot_gc_shenandoah` >> - [x] Linux x86_64 `tier1` with Shenandoah > > Thanks for catching this. Looks good. > > Concurrent mark resets qstats in ShenandoahConcurrentMark::mark_stw_roots(), so it should be fine. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/2141 From zgu at openjdk.java.net Tue Jan 19 18:09:53 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 19 Jan 2021 18:09:53 GMT Subject: RFR: 8255765: Shenandoah: Isolate concurrent, degenerated and full GC In-Reply-To: References: <9sUK197ZPOSEPLEDl8zKSqby-KMi9FryXnoctOdWmMc=.7b678df1-1c51-4bbf-b1a3-d8a8167a927d@github.com> Message-ID: On Tue, 19 Jan 2021 12:05:19 GMT, Aleksey Shipilev wrote: >> The purpose of this patch is to isolate concurrent, degenerated and full gc implementation, so that, makes each GC implementation more straightforward and clean, and improves readability. >> >> Current implementation emphasis code sharing, e.g. degenerated GC reuses concurrent GC's ops. It was not a problem in the beginning, when they actually behave similarly. Since concurrent GC moved root processing into concurrent phases, code started to diverge, we started to put bandages to make the shared ops work for both concurrent and degenerated GC, that made code hard to read and error prone. >> >> The patch breaks up GCs into 3 (mainly just concurrent and degenerated GC, as full GC already standalone) easy to identify and understand classes (ShenandoahConcurrentGC, ShenandoahDegeneratedGC and ShenandoahMarkCompactGC), subclasses of ShenandoahGC class. >> >> The three GCs still keep vmop/entry/op paradigm, but encapsulate GC control flow inside their own classes, as ShenandoahMarkCompact GC already does. So that, concurrent and degenerated GC no longer share ops and op implementations no longer need to consider other GC modes, which results in simplifying implementation and improving readability. Code sharing is achieved via helper methods provided by ShenandoahHeap. >> >> Test: >> - [x] hotspot_gc_shenandoah >> - [x] nightly tests > > src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp line 196: > >> 194: >> 195: if (!heap->unload_classes()) { >> 196: _cld_roots.cld_do(&clds_cl, worker_id); > > This change seems unrelated? Right. Restored and will file a separate bug to clean it up. ------------- PR: https://git.openjdk.java.net/jdk/pull/1964 From zgu at openjdk.java.net Tue Jan 19 18:24:04 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 19 Jan 2021 18:24:04 GMT Subject: RFR: 8255765: Shenandoah: Isolate concurrent, degenerated and full GC [v2] In-Reply-To: <9sUK197ZPOSEPLEDl8zKSqby-KMi9FryXnoctOdWmMc=.7b678df1-1c51-4bbf-b1a3-d8a8167a927d@github.com> References: <9sUK197ZPOSEPLEDl8zKSqby-KMi9FryXnoctOdWmMc=.7b678df1-1c51-4bbf-b1a3-d8a8167a927d@github.com> Message-ID: > The purpose of this patch is to isolate concurrent, degenerated and full gc implementation, so that, makes each GC implementation more straightforward and clean, and improves readability. > > Current implementation emphasis code sharing, e.g. degenerated GC reuses concurrent GC's ops. It was not a problem in the beginning, when they actually behave similarly. Since concurrent GC moved root processing into concurrent phases, code started to diverge, we started to put bandages to make the shared ops work for both concurrent and degenerated GC, that made code hard to read and error prone. > > The patch breaks up GCs into 3 (mainly just concurrent and degenerated GC, as full GC already standalone) easy to identify and understand classes (ShenandoahConcurrentGC, ShenandoahDegeneratedGC and ShenandoahMarkCompactGC), subclasses of ShenandoahGC class. > > The three GCs still keep vmop/entry/op paradigm, but encapsulate GC control flow inside their own classes, as ShenandoahMarkCompact GC already does. So that, concurrent and degenerated GC no longer share ops and op implementations no longer need to consider other GC modes, which results in simplifying implementation and improving readability. Code sharing is achieved via helper methods provided by ShenandoahHeap. > > Test: > - [x] hotspot_gc_shenandoah > - [x] nightly tests Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Aleksey's comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1964/files - new: https://git.openjdk.java.net/jdk/pull/1964/files/d9805040..93b2ceed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1964&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1964&range=00-01 Stats: 32 lines in 7 files changed: 3 ins; 15 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/1964.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1964/head:pull/1964 PR: https://git.openjdk.java.net/jdk/pull/1964 From zgu at openjdk.java.net Tue Jan 19 19:34:02 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 19 Jan 2021 19:34:02 GMT Subject: RFR: 8255765: Shenandoah: Isolate concurrent, degenerated and full GC [v3] In-Reply-To: <9sUK197ZPOSEPLEDl8zKSqby-KMi9FryXnoctOdWmMc=.7b678df1-1c51-4bbf-b1a3-d8a8167a927d@github.com> References: <9sUK197ZPOSEPLEDl8zKSqby-KMi9FryXnoctOdWmMc=.7b678df1-1c51-4bbf-b1a3-d8a8167a927d@github.com> Message-ID: > The purpose of this patch is to isolate concurrent, degenerated and full gc implementation, so that, makes each GC implementation more straightforward and clean, and improves readability. > > Current implementation emphasis code sharing, e.g. degenerated GC reuses concurrent GC's ops. It was not a problem in the beginning, when they actually behave similarly. Since concurrent GC moved root processing into concurrent phases, code started to diverge, we started to put bandages to make the shared ops work for both concurrent and degenerated GC, that made code hard to read and error prone. > > The patch breaks up GCs into 3 (mainly just concurrent and degenerated GC, as full GC already standalone) easy to identify and understand classes (ShenandoahConcurrentGC, ShenandoahDegeneratedGC and ShenandoahMarkCompactGC), subclasses of ShenandoahGC class. > > The three GCs still keep vmop/entry/op paradigm, but encapsulate GC control flow inside their own classes, as ShenandoahMarkCompact GC already does. So that, concurrent and degenerated GC no longer share ops and op implementations no longer need to consider other GC modes, which results in simplifying implementation and improving readability. Code sharing is achieved via helper methods provided by ShenandoahHeap. > > Test: > - [x] hotspot_gc_shenandoah > - [x] nightly tests Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 101 commits: - Merge branch 'master' into JDK-8255765-isolate-gcs - Aleksey's comments - Remove cached heap in ShenandoahGC - Merge - Merge branch 'fix_phase_timings' into JDK-8255765-isolate-gcs - Merge - Merge - Merge - Merge - Removed trailing whitespaces - ... and 91 more: https://git.openjdk.java.net/jdk/compare/3edf393d...4e54d38d ------------- Changes: https://git.openjdk.java.net/jdk/pull/1964/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1964&range=02 Stats: 3218 lines in 20 files changed: 1802 ins; 1280 del; 136 mod Patch: https://git.openjdk.java.net/jdk/pull/1964.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1964/head:pull/1964 PR: https://git.openjdk.java.net/jdk/pull/1964 From zgu at openjdk.java.net Tue Jan 19 22:14:56 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 19 Jan 2021 22:14:56 GMT Subject: RFR: 8260005: Shenandoah: Remove unused AlwaysTrueClosure in ShenandoahConcurrentRootScanner::roots_do() Message-ID: Please review this trivial cleanup that removes unused AlwaysTrueClosure in ShenandoahConcurrentRootScanner::roots_do() Test: - [x] hotspot_gc_shenandoah ------------- Commit messages: - Init update Changes: https://git.openjdk.java.net/jdk/pull/2152/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2152&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260005 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2152.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2152/head:pull/2152 PR: https://git.openjdk.java.net/jdk/pull/2152 From shade at openjdk.java.net Tue Jan 19 22:19:48 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 19 Jan 2021 22:19:48 GMT Subject: Withdrawn: 8256949: Shenandoah: ditch allocation spike and GC penalties handling In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 12:53:29 GMT, Aleksey Shipilev wrote: > Following the improvements in JDK-8255984, I think we can dispense with old-style allocation spike and GC penalties handling. JDK-8255984 is supposed to accommodate both cases now. This issue is to have a base for performance evaluation. > > Additional testing: > - [x] Linux x86_64 `hotspot_gc_shenandoah` This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1409 From gnu.andrew at redhat.com Wed Jan 20 03:28:42 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 20 Jan 2021 03:28:42 +0000 Subject: [RFR] [8u] 8u282-b08 Upstream Sync Message-ID: <20210120032842.GA1179631@rincewind> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/root/merge.changeset Changes in aarch64-shenandoah-jdk8u282-b08: - JDK-8247619: Improve Direct Buffering of Characters Main issues of note: None, clean merge (no HotSpot changes). diffstat for root b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for corba b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxp b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxws b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for langtools b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for nashorn b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jdk b/.hgtags | 1 b/src/share/classes/java/nio/Buffer.java | 5 ++- b/src/share/classes/java/nio/Heap-X-Buffer.java.template | 6 +++- b/src/share/classes/java/nio/X-Buffer.java.template | 20 ++++++++++----- 4 files changed, 22 insertions(+), 10 deletions(-) diffstat for hotspot b/.hgtags | 1 + 1 file changed, 1 insertion(+) Successfully built on x86, x86_64, s390 (Zero), s390x (Zero), ppc (Zero), ppc64, ppc64le & aarch64. Ok to push? Thanks, -- Andrew :) 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 shade at openjdk.java.net Wed Jan 20 07:53:57 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 20 Jan 2021 07:53:57 GMT Subject: RFR: 8260005: Shenandoah: Remove unused AlwaysTrueClosure in ShenandoahConcurrentRootScanner::roots_do() In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 22:09:49 GMT, Zhengyu Gu wrote: > Please review this trivial cleanup that removes unused AlwaysTrueClosure in ShenandoahConcurrentRootScanner::roots_do() > > Test: > - [x] hotspot_gc_shenandoah Looks fine and trivial. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2152 From shade at redhat.com Wed Jan 20 09:59:01 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 Jan 2021 10:59:01 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u282-b08 Upstream Sync In-Reply-To: <20210120032842.GA1179631@rincewind> References: <20210120032842.GA1179631@rincewind> Message-ID: <16d3bc59-4a2f-e366-5510-dab854849145@redhat.com> On 1/20/21 4:28 AM, Andrew Hughes wrote: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/jaxws/merge.changeset Look trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/jdk/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/hotspot/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/root/merge.changeset Look trivially good. > Ok to push? Yes. -- Thanks, -Aleksey From rkennke at openjdk.java.net Wed Jan 20 10:01:38 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 20 Jan 2021 10:01:38 GMT Subject: RFR: 8260005: Shenandoah: Remove unused AlwaysTrueClosure in ShenandoahConcurrentRootScanner::roots_do() In-Reply-To: References: Message-ID: <3ywjav1EJRHYLQIPPF73PHJ2hUfTr4eOe7TmTd_ljS0=.d78d98eb-6dbd-443b-bf3a-9be824a50769@github.com> On Tue, 19 Jan 2021 22:09:49 GMT, Zhengyu Gu wrote: > Please review this trivial cleanup that removes unused AlwaysTrueClosure in ShenandoahConcurrentRootScanner::roots_do() > > Test: > - [x] hotspot_gc_shenandoah Looks good and trivial. ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2152 From zgu at openjdk.java.net Wed Jan 20 13:14:56 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 20 Jan 2021 13:14:56 GMT Subject: Integrated: 8260005: Shenandoah: Remove unused AlwaysTrueClosure in ShenandoahConcurrentRootScanner::roots_do() In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 22:09:49 GMT, Zhengyu Gu wrote: > Please review this trivial cleanup that removes unused AlwaysTrueClosure in ShenandoahConcurrentRootScanner::roots_do() > > Test: > - [x] hotspot_gc_shenandoah This pull request has now been integrated. Changeset: 0b01d692 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/0b01d692 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8260005: Shenandoah: Remove unused AlwaysTrueClosure in ShenandoahConcurrentRootScanner::roots_do() Reviewed-by: shade, rkennke ------------- PR: https://git.openjdk.java.net/jdk/pull/2152 From shade at openjdk.java.net Wed Jan 20 13:28:08 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 20 Jan 2021 13:28:08 GMT Subject: RFR: 8260048: Shenandoah: ShenandoahMarkingContext asserts are unnecessary Message-ID: There are two `shenandoah_assert_not_forwarded` asserts that are not necessary in `mark_{strong,weak}`, because the only caller [already asserts](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp#L272) this higher-level invariant. There is no need to check it in `ShenandoahMarkingContext` once again. This simplifies the fastpath in fastdebug builds. Additional testing: - [x] `hotspot_gc_shenandoah` - [x] `tier1`, `tier2` with Shenandoah ------------- Commit messages: - Drop a few more parentheses - 8260048: Shenandoah: ShenandoahMarkingContext asserts are unnecessary Changes: https://git.openjdk.java.net/jdk/pull/2164/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2164&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260048 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2164.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2164/head:pull/2164 PR: https://git.openjdk.java.net/jdk/pull/2164 From zgu at openjdk.java.net Wed Jan 20 13:53:38 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 20 Jan 2021 13:53:38 GMT Subject: RFR: 8260048: Shenandoah: ShenandoahMarkingContext asserts are unnecessary In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 13:20:41 GMT, Aleksey Shipilev wrote: > There are two `shenandoah_assert_not_forwarded` asserts that are not necessary in `mark_{strong,weak}`, because the only caller [already asserts](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp#L272) this higher-level invariant. There is no need to check it in `ShenandoahMarkingContext` once again. This simplifies the fastpath in fastdebug builds. > > Additional testing: > - [x] `hotspot_gc_shenandoah` > - [x] `tier1`, `tier2` with Shenandoah Looks good and trivial. ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2164 From zgu at openjdk.java.net Wed Jan 20 15:12:00 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 20 Jan 2021 15:12:00 GMT Subject: RFR: 8259488: Shenandoah: Missing timing tracking for STW CLD root processing Message-ID: <5Ym9NRL-jXY5JFNIfjdsxSO_W25fV-uP8uQryx2CcUw=.082669c1-3063-4412-b578-f1b86f3c59e9@github.com> Please review this trivial patch that adds missing timing tracking for STW CLD root processing. - [x] hotspot_gc_shenandoah ------------- Commit messages: - JDK-8259488 Changes: https://git.openjdk.java.net/jdk/pull/2165/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2165&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259488 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2165.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2165/head:pull/2165 PR: https://git.openjdk.java.net/jdk/pull/2165 From shade at openjdk.java.net Wed Jan 20 15:12:59 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 20 Jan 2021 15:12:59 GMT Subject: RFR: 8260106: Shenandoah: simplify maybe_update_with_forwarded and related code Message-ID: We have a block in `ShenandoahHeap::maybe_update_with_forwarded` that is irrelevant after JDK-8231086. Additionally, "resolve and update" paths are really only used by STW GCs, and thus do not require atomic updates. This leads to considerable simplifications in the code, and improves performance on the common paths (especially in fastdebug builds that drop many irrelevant asserts). Additional testing: - [x] `hotspot_gc_shenandoah` - [ ] `tier1` with Shenandoah - [ ] `tier2` with Shenandoah ------------- Commit messages: - 8260106: Shenandoah: simplify maybe_update_with_forwarded and related code Changes: https://git.openjdk.java.net/jdk/pull/2166/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2166&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260106 Stats: 147 lines in 4 files changed: 19 ins; 84 del; 44 mod Patch: https://git.openjdk.java.net/jdk/pull/2166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2166/head:pull/2166 PR: https://git.openjdk.java.net/jdk/pull/2166 From shade at openjdk.java.net Wed Jan 20 18:55:53 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 20 Jan 2021 18:55:53 GMT Subject: RFR: 8259488: Shenandoah: Missing timing tracking for STW CLD root processing In-Reply-To: <5Ym9NRL-jXY5JFNIfjdsxSO_W25fV-uP8uQryx2CcUw=.082669c1-3063-4412-b578-f1b86f3c59e9@github.com> References: <5Ym9NRL-jXY5JFNIfjdsxSO_W25fV-uP8uQryx2CcUw=.082669c1-3063-4412-b578-f1b86f3c59e9@github.com> Message-ID: On Wed, 20 Jan 2021 15:04:55 GMT, Zhengyu Gu wrote: > Please review this trivial patch that adds missing timing tracking for STW CLD root processing. > > - [x] hotspot_gc_shenandoah Looks good. Please wait for tests ("Checks" tab) to complete anyway, in case tracking runs into any kind of assert. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2165 From zgu at openjdk.java.net Wed Jan 20 19:13:51 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 20 Jan 2021 19:13:51 GMT Subject: RFR: 8260106: Shenandoah: simplify maybe_update_with_forwarded and related code In-Reply-To: References: Message-ID: <_wIuAaUBJdBGdD4lrDUdS5f2dv4aZJqcAvqWA22qOeQ=.d73a77a1-80a2-46ba-b728-b461b67b738e@github.com> On Wed, 20 Jan 2021 15:06:20 GMT, Aleksey Shipilev wrote: > We have a block in `ShenandoahHeap::maybe_update_with_forwarded` that is irrelevant after JDK-8231086. Additionally, "resolve and update" paths are really only used by STW GCs, and thus do not require atomic updates. This leads to considerable simplifications in the code, and improves performance on the common paths (especially in fastdebug builds that drop many irrelevant asserts). > > Additional testing: > - [x] `hotspot_gc_shenandoah` > - [ ] `tier1` with Shenandoah > - [ ] `tier2` with Shenandoah Looks good. Please update copyright years of shenandoahHeap.inline.hpp and shenandoahOopClosures.hpp ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2166 From rkennke at openjdk.java.net Wed Jan 20 19:49:49 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 20 Jan 2021 19:49:49 GMT Subject: RFR: 8260048: Shenandoah: ShenandoahMarkingContext asserts are unnecessary In-Reply-To: References: Message-ID: <_V3GudSNRag1N31V9DupSgnsRmLBMQdyLVuFAv9e3HE=.bd0c5ead-948d-4c62-b2a9-4c01e36453cd@github.com> On Wed, 20 Jan 2021 13:20:41 GMT, Aleksey Shipilev wrote: > There are two `shenandoah_assert_not_forwarded` asserts that are not necessary in `mark_{strong,weak}`, because the only caller [already asserts](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp#L272) this higher-level invariant. There is no need to check it in `ShenandoahMarkingContext` once again. This simplifies the fastpath in fastdebug builds. > > Additional testing: > - [x] `hotspot_gc_shenandoah` > - [x] `tier1`, `tier2` with Shenandoah Ok. ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2164 From rkennke at openjdk.java.net Wed Jan 20 19:56:48 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 20 Jan 2021 19:56:48 GMT Subject: RFR: 8260106: Shenandoah: simplify maybe_update_with_forwarded and related code In-Reply-To: References: Message-ID: <7qUIYyY5EsilZrrh2KWDmw2zU9O_J56xsLQ1_ztVzqE=.c36234af-f3cf-4ce8-a299-be8213b70f4b@github.com> On Wed, 20 Jan 2021 15:06:20 GMT, Aleksey Shipilev wrote: > We have a block in `ShenandoahHeap::maybe_update_with_forwarded` that is irrelevant after JDK-8231086. Additionally, "resolve and update" paths are really only used by STW GCs, and thus do not require atomic updates. This leads to considerable simplifications in the code, and improves performance on the common paths (especially in fastdebug builds that drop many irrelevant asserts). > > Additional testing: > - [x] `hotspot_gc_shenandoah` > - [ ] `tier1` with Shenandoah > - [ ] `tier2` with Shenandoah Nice! Few nits below. src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 120: > 118: shenandoah_assert_not_in_cset_except(p, fwd, cancelled_gc()); > 119: > 120: // Sanity check: we are should not be updating the cset regions themselves, Typo: excess 'are' (I think) ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2166 From zgu at openjdk.java.net Wed Jan 20 21:45:58 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 20 Jan 2021 21:45:58 GMT Subject: Integrated: 8259488: Shenandoah: Missing timing tracking for STW CLD root processing In-Reply-To: <5Ym9NRL-jXY5JFNIfjdsxSO_W25fV-uP8uQryx2CcUw=.082669c1-3063-4412-b578-f1b86f3c59e9@github.com> References: <5Ym9NRL-jXY5JFNIfjdsxSO_W25fV-uP8uQryx2CcUw=.082669c1-3063-4412-b578-f1b86f3c59e9@github.com> Message-ID: On Wed, 20 Jan 2021 15:04:55 GMT, Zhengyu Gu wrote: > Please review this trivial patch that adds missing timing tracking for STW CLD root processing. > > - [x] hotspot_gc_shenandoah This pull request has now been integrated. Changeset: 4f11ff32 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/4f11ff32 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8259488: Shenandoah: Missing timing tracking for STW CLD root processing Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/2165 From shade at openjdk.java.net Thu Jan 21 07:24:56 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 21 Jan 2021 07:24:56 GMT Subject: Integrated: 8260048: Shenandoah: ShenandoahMarkingContext asserts are unnecessary In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 13:20:41 GMT, Aleksey Shipilev wrote: > There are two `shenandoah_assert_not_forwarded` asserts that are not necessary in `mark_{strong,weak}`, because the only caller [already asserts](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp#L272) this higher-level invariant. There is no need to check it in `ShenandoahMarkingContext` once again. This simplifies the fastpath in fastdebug builds. > > Additional testing: > - [x] `hotspot_gc_shenandoah` > - [x] `tier1`, `tier2` with Shenandoah This pull request has now been integrated. Changeset: 5940287b Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/5940287b Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod 8260048: Shenandoah: ShenandoahMarkingContext asserts are unnecessary Reviewed-by: zgu, rkennke ------------- PR: https://git.openjdk.java.net/jdk/pull/2164 From shade at openjdk.java.net Thu Jan 21 08:06:11 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 21 Jan 2021 08:06:11 GMT Subject: RFR: 8260106: Shenandoah: simplify maybe_update_with_forwarded and related code [v2] In-Reply-To: <7qUIYyY5EsilZrrh2KWDmw2zU9O_J56xsLQ1_ztVzqE=.c36234af-f3cf-4ce8-a299-be8213b70f4b@github.com> References: <7qUIYyY5EsilZrrh2KWDmw2zU9O_J56xsLQ1_ztVzqE=.c36234af-f3cf-4ce8-a299-be8213b70f4b@github.com> Message-ID: On Wed, 20 Jan 2021 19:50:41 GMT, Roman Kennke wrote: >> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: >> >> - Rename maybe to atomic >> - Touch up comments > > src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 120: > >> 118: shenandoah_assert_not_in_cset_except(p, fwd, cancelled_gc()); >> 119: >> 120: // Sanity check: we are should not be updating the cset regions themselves, > > Typo: excess 'are' (I think) Resolved, along with a few other touchups. ------------- PR: https://git.openjdk.java.net/jdk/pull/2166 From shade at openjdk.java.net Thu Jan 21 08:06:10 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 21 Jan 2021 08:06:10 GMT Subject: RFR: 8260106: Shenandoah: simplify maybe_update_with_forwarded and related code [v2] In-Reply-To: References: Message-ID: <6kABGv_phymIASILTHYVqGaQf6Lu7tgqj4wQYibNYaA=.12ef2e99-9d24-4a15-be74-aaf468cd0ca5@github.com> > We have a block in `ShenandoahHeap::maybe_update_with_forwarded` that is irrelevant after JDK-8231086. Additionally, "resolve and update" paths are really only used by STW GCs, and thus do not require atomic updates. This leads to considerable simplifications in the code, and improves performance on the common paths (especially in fastdebug builds that drop many irrelevant asserts). > > Additional testing: > - [x] `hotspot_gc_shenandoah` > - [ ] `tier1` with Shenandoah > - [ ] `tier2` with Shenandoah Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: - Rename maybe to atomic - Touch up comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2166/files - new: https://git.openjdk.java.net/jdk/pull/2166/files/88c15df1..764ec461 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2166&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2166&range=00-01 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2166/head:pull/2166 PR: https://git.openjdk.java.net/jdk/pull/2166 From shade at openjdk.java.net Thu Jan 21 08:32:10 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 21 Jan 2021 08:32:10 GMT Subject: RFR: 8255765: Shenandoah: Isolate concurrent, degenerated and full GC [v3] In-Reply-To: References: <9sUK197ZPOSEPLEDl8zKSqby-KMi9FryXnoctOdWmMc=.7b678df1-1c51-4bbf-b1a3-d8a8167a927d@github.com> Message-ID: On Tue, 19 Jan 2021 19:34:02 GMT, Zhengyu Gu wrote: >> The purpose of this patch is to isolate concurrent, degenerated and full gc implementation, so that, makes each GC implementation more straightforward and clean, and improves readability. >> >> Current implementation emphasis code sharing, e.g. degenerated GC reuses concurrent GC's ops. It was not a problem in the beginning, when they actually behave similarly. Since concurrent GC moved root processing into concurrent phases, code started to diverge, we started to put bandages to make the shared ops work for both concurrent and degenerated GC, that made code hard to read and error prone. >> >> The patch breaks up GCs into 3 (mainly just concurrent and degenerated GC, as full GC already standalone) easy to identify and understand classes (ShenandoahConcurrentGC, ShenandoahDegeneratedGC and ShenandoahMarkCompactGC), subclasses of ShenandoahGC class. >> >> The three GCs still keep vmop/entry/op paradigm, but encapsulate GC control flow inside their own classes, as ShenandoahMarkCompact GC already does. So that, concurrent and degenerated GC no longer share ops and op implementations no longer need to consider other GC modes, which results in simplifying implementation and improving readability. Code sharing is achieved via helper methods provided by ShenandoahHeap. >> >> Test: >> - [x] hotspot_gc_shenandoah >> - [x] nightly tests > > Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 101 commits: > > - Merge branch 'master' into JDK-8255765-isolate-gcs > - Aleksey's comments > - Remove cached heap in ShenandoahGC > - Merge > - Merge branch 'fix_phase_timings' into JDK-8255765-isolate-gcs > - Merge > - Merge > - Merge > - Merge > - Removed trailing whitespaces > - ... and 91 more: https://git.openjdk.java.net/jdk/compare/3edf393d...4e54d38d I have only minor nits left. src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 412: > 410: } > 411: > 412: // Actual work for the phases I think we can drop this comment. src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 659: > 657: } > 658: > 659: _dedup_roots.prologue(); It looks to me this line in misindented: one stray space? src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp line 115: > 113: // STW mark > 114: op_mark(); > 115: case _degenerated_mark: New line before this `case`? src/hotspot/share/gc/shenandoah/shenandoahGC.hpp line 66: > 64: }; > 65: > 66: #endif Should be `#endif // SHARE_GC_SHENANDOAH_SHENANDOAHGC_HPP`? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1964 From shade at openjdk.java.net Thu Jan 21 08:37:05 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 21 Jan 2021 08:37:05 GMT Subject: RFR: 8260212: Shenandoah: resolve-only UpdateRefsMode is not used Message-ID: The only "use" is `ShenandoahMarkResolveRefsClosure`, which is unused itself. ------------- Commit messages: - 8260212: Shenandoah: resolve-only UpdateRefsMode is not used Changes: https://git.openjdk.java.net/jdk/pull/2177/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2177&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260212 Stats: 18 lines in 2 files changed: 0 ins; 18 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2177.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2177/head:pull/2177 PR: https://git.openjdk.java.net/jdk/pull/2177 From rkennke at openjdk.java.net Thu Jan 21 09:01:52 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 21 Jan 2021 09:01:52 GMT Subject: RFR: 8260106: Shenandoah: simplify maybe_update_with_forwarded and related code [v2] In-Reply-To: <6kABGv_phymIASILTHYVqGaQf6Lu7tgqj4wQYibNYaA=.12ef2e99-9d24-4a15-be74-aaf468cd0ca5@github.com> References: <6kABGv_phymIASILTHYVqGaQf6Lu7tgqj4wQYibNYaA=.12ef2e99-9d24-4a15-be74-aaf468cd0ca5@github.com> Message-ID: On Thu, 21 Jan 2021 08:06:10 GMT, Aleksey Shipilev wrote: >> We have a block in `ShenandoahHeap::maybe_update_with_forwarded` that is irrelevant after JDK-8231086. Additionally, "resolve and update" paths are really only used by STW GCs, and thus do not require atomic updates. This leads to considerable simplifications in the code, and improves performance on the common paths (especially in fastdebug builds that drop many irrelevant asserts). >> >> Additional testing: >> - [x] `hotspot_gc_shenandoah` >> - [ ] `tier1` with Shenandoah >> - [ ] `tier2` with Shenandoah > > Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: > > - Rename maybe to atomic > - Touch up comments Looks good! Thanks! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2166 From rkennke at openjdk.java.net Thu Jan 21 09:04:01 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 21 Jan 2021 09:04:01 GMT Subject: RFR: 8260212: Shenandoah: resolve-only UpdateRefsMode is not used In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 08:31:36 GMT, Aleksey Shipilev wrote: > The only "use" is `ShenandoahMarkResolveRefsClosure`, which is unused itself. Looks good! (Wow, this really goes up in smoke, doesn't it?) ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2177 From shade at openjdk.java.net Thu Jan 21 09:15:09 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 21 Jan 2021 09:15:09 GMT Subject: RFR: 8259954: gc/shenandoah/mxbeans tests fail with -Xcomp Message-ID: See the bug report for initial observation. The key thing is that the asynchronous GC notifications can arrive late, and they do arrive late with `-Xcomp`, because all that code is now waiting for compilation. The answer is to wait a bit smarter. Additional testing: - [x] `gc/shenandoah/mxbeans` default mode - [x] `gc/shenandoah/mxbeans` with `-Xcomp` - [x] `gc/shenandoah/mxbeans` with `-Xint` ------------- Commit messages: - 8259954: gc/shenandoah/mxbeans tests fail with -Xcomp Changes: https://git.openjdk.java.net/jdk/pull/2179/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2179&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259954 Stats: 12 lines in 2 files changed: 10 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2179.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2179/head:pull/2179 PR: https://git.openjdk.java.net/jdk/pull/2179 From github.com+10482586+therealeliu at openjdk.java.net Thu Jan 21 09:59:54 2021 From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu) Date: Thu, 21 Jan 2021 09:59:54 GMT Subject: RFR: 8259954: gc/shenandoah/mxbeans tests fail with -Xcomp In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 09:09:22 GMT, Aleksey Shipilev wrote: > See the bug report for initial observation. The key thing is that the asynchronous GC notifications can arrive late, and they do arrive late with `-Xcomp`, because all that code is now waiting for compilation. The answer is to wait a bit smarter. > > Additional testing: > - [x] `gc/shenandoah/mxbeans` default mode > - [x] `gc/shenandoah/mxbeans` with `-Xcomp` > - [x] `gc/shenandoah/mxbeans` with `-Xint` test/hotspot/jtreg/gc/shenandoah/mxbeans/TestChurnNotifications.java line 167: > 165: Thread.sleep(1000); > 166: } > 167: Thread.sleep(5000); I was wandering if it's necessary to handle the timeout by the code itself instead of delegating to jtreg? In the worst case, that's a really long time about 960000ms. ------------- PR: https://git.openjdk.java.net/jdk/pull/2179 From shade at openjdk.java.net Thu Jan 21 10:04:02 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 21 Jan 2021 10:04:02 GMT Subject: RFR: 8259954: gc/shenandoah/mxbeans tests fail with -Xcomp In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 09:56:29 GMT, Eric Liu wrote: >> See the bug report for initial observation. The key thing is that the asynchronous GC notifications can arrive late, and they do arrive late with `-Xcomp`, because all that code is now waiting for compilation. The answer is to wait a bit smarter. >> >> Additional testing: >> - [x] `gc/shenandoah/mxbeans` default mode >> - [x] `gc/shenandoah/mxbeans` with `-Xcomp` >> - [x] `gc/shenandoah/mxbeans` with `-Xint` > > test/hotspot/jtreg/gc/shenandoah/mxbeans/TestChurnNotifications.java line 167: > >> 165: Thread.sleep(1000); >> 166: } >> 167: Thread.sleep(5000); > > I was wandering if it's necessary to handle the timeout by the code itself instead of delegating to jtreg? In the worst case, that's a really long time about 960000ms. Yeah, I was wondering about the same when doing that chunk, but then argued to myself that timeout might be as well handled by jtreg. Mostly because in many cases JTREG_TIMEOUT_FACTOR is passed to control the machine-dependent behavior: slower/overloaded machines get larger timeout factors configured. Hardcoding the timeouts in the test would deprive us of this "feature". ------------- PR: https://git.openjdk.java.net/jdk/pull/2179 From github.com+10482586+therealeliu at openjdk.java.net Thu Jan 21 10:15:55 2021 From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu) Date: Thu, 21 Jan 2021 10:15:55 GMT Subject: RFR: 8259954: gc/shenandoah/mxbeans tests fail with -Xcomp In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 10:00:30 GMT, Aleksey Shipilev wrote: >> test/hotspot/jtreg/gc/shenandoah/mxbeans/TestChurnNotifications.java line 167: >> >>> 165: Thread.sleep(1000); >>> 166: } >>> 167: Thread.sleep(5000); >> >> I was wandering if it's necessary to handle the timeout by the code itself instead of delegating to jtreg? In the worst case, that's a really long time about 960000ms. > > Yeah, I was wondering about the same when doing that chunk, but then argued to myself that timeout might be as well handled by jtreg. Mostly because in many cases JTREG_TIMEOUT_FACTOR is passed to control the machine-dependent behavior: slower/overloaded machines get larger timeout factors configured. Hardcoding the timeouts in the test would deprive us of this "feature". Thanks, that's make sense to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/2179 From rkennke at openjdk.java.net Thu Jan 21 11:18:54 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 21 Jan 2021 11:18:54 GMT Subject: RFR: 8259954: gc/shenandoah/mxbeans tests fail with -Xcomp In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 09:09:22 GMT, Aleksey Shipilev wrote: > See the bug report for initial observation. The key thing is that the asynchronous GC notifications can arrive late, and they do arrive late with `-Xcomp`, because all that code is now waiting for compilation. The answer is to wait a bit smarter. > > Additional testing: > - [x] `gc/shenandoah/mxbeans` default mode > - [x] `gc/shenandoah/mxbeans` with `-Xcomp` > - [x] `gc/shenandoah/mxbeans` with `-Xint` Ok. ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2179 From zgu at openjdk.java.net Thu Jan 21 13:27:17 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 21 Jan 2021 13:27:17 GMT Subject: RFR: 8259954: gc/shenandoah/mxbeans tests fail with -Xcomp In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 09:09:22 GMT, Aleksey Shipilev wrote: > See the bug report for initial observation. The key thing is that the asynchronous GC notifications can arrive late, and they do arrive late with `-Xcomp`, because all that code is now waiting for compilation. The answer is to wait a bit smarter. > > Additional testing: > - [x] `gc/shenandoah/mxbeans` default mode > - [x] `gc/shenandoah/mxbeans` with `-Xcomp` > - [x] `gc/shenandoah/mxbeans` with `-Xint` Okay. ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2179 From shade at openjdk.java.net Thu Jan 21 13:36:27 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 21 Jan 2021 13:36:27 GMT Subject: Integrated: 8259954: gc/shenandoah/mxbeans tests fail with -Xcomp In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 09:09:22 GMT, Aleksey Shipilev wrote: > See the bug report for initial observation. The key thing is that the asynchronous GC notifications can arrive late, and they do arrive late with `-Xcomp`, because all that code is now waiting for compilation. The answer is to wait a bit smarter. > > Additional testing: > - [x] `gc/shenandoah/mxbeans` default mode > - [x] `gc/shenandoah/mxbeans` with `-Xcomp` > - [x] `gc/shenandoah/mxbeans` with `-Xint` This pull request has now been integrated. Changeset: c3c66625 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/c3c66625 Stats: 12 lines in 2 files changed: 10 ins; 0 del; 2 mod 8259954: gc/shenandoah/mxbeans tests fail with -Xcomp Reviewed-by: rkennke, zgu ------------- PR: https://git.openjdk.java.net/jdk/pull/2179 From zgu at openjdk.java.net Thu Jan 21 13:38:36 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 21 Jan 2021 13:38:36 GMT Subject: RFR: 8255765: Shenandoah: Isolate concurrent, degenerated and full GC [v4] In-Reply-To: <9sUK197ZPOSEPLEDl8zKSqby-KMi9FryXnoctOdWmMc=.7b678df1-1c51-4bbf-b1a3-d8a8167a927d@github.com> References: <9sUK197ZPOSEPLEDl8zKSqby-KMi9FryXnoctOdWmMc=.7b678df1-1c51-4bbf-b1a3-d8a8167a927d@github.com> Message-ID: <09bd9-Ql3GxB5ELAGppBGDqXuTJeKN2QDMhYlk6f8RU=.2389637d-0d0a-4d7b-9002-4ebc0c551007@github.com> > The purpose of this patch is to isolate concurrent, degenerated and full gc implementation, so that, makes each GC implementation more straightforward and clean, and improves readability. > > Current implementation emphasis code sharing, e.g. degenerated GC reuses concurrent GC's ops. It was not a problem in the beginning, when they actually behave similarly. Since concurrent GC moved root processing into concurrent phases, code started to diverge, we started to put bandages to make the shared ops work for both concurrent and degenerated GC, that made code hard to read and error prone. > > The patch breaks up GCs into 3 (mainly just concurrent and degenerated GC, as full GC already standalone) easy to identify and understand classes (ShenandoahConcurrentGC, ShenandoahDegeneratedGC and ShenandoahMarkCompactGC), subclasses of ShenandoahGC class. > > The three GCs still keep vmop/entry/op paradigm, but encapsulate GC control flow inside their own classes, as ShenandoahMarkCompact GC already does. So that, concurrent and degenerated GC no longer share ops and op implementations no longer need to consider other GC modes, which results in simplifying implementation and improving readability. Code sharing is achieved via helper methods provided by ShenandoahHeap. > > Test: > - [x] hotspot_gc_shenandoah > - [x] nightly tests Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: More from Aleksey's review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1964/files - new: https://git.openjdk.java.net/jdk/pull/1964/files/4e54d38d..514aac66 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1964&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1964&range=02-03 Stats: 3 lines in 3 files changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1964.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1964/head:pull/1964 PR: https://git.openjdk.java.net/jdk/pull/1964 From zgu at openjdk.java.net Thu Jan 21 13:44:53 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 21 Jan 2021 13:44:53 GMT Subject: RFR: 8255765: Shenandoah: Isolate concurrent, degenerated and full GC [v5] In-Reply-To: <9sUK197ZPOSEPLEDl8zKSqby-KMi9FryXnoctOdWmMc=.7b678df1-1c51-4bbf-b1a3-d8a8167a927d@github.com> References: <9sUK197ZPOSEPLEDl8zKSqby-KMi9FryXnoctOdWmMc=.7b678df1-1c51-4bbf-b1a3-d8a8167a927d@github.com> Message-ID: > The purpose of this patch is to isolate concurrent, degenerated and full gc implementation, so that, makes each GC implementation more straightforward and clean, and improves readability. > > Current implementation emphasis code sharing, e.g. degenerated GC reuses concurrent GC's ops. It was not a problem in the beginning, when they actually behave similarly. Since concurrent GC moved root processing into concurrent phases, code started to diverge, we started to put bandages to make the shared ops work for both concurrent and degenerated GC, that made code hard to read and error prone. > > The patch breaks up GCs into 3 (mainly just concurrent and degenerated GC, as full GC already standalone) easy to identify and understand classes (ShenandoahConcurrentGC, ShenandoahDegeneratedGC and ShenandoahMarkCompactGC), subclasses of ShenandoahGC class. > > The three GCs still keep vmop/entry/op paradigm, but encapsulate GC control flow inside their own classes, as ShenandoahMarkCompact GC already does. So that, concurrent and degenerated GC no longer share ops and op implementations no longer need to consider other GC modes, which results in simplifying implementation and improving readability. Code sharing is achieved via helper methods provided by ShenandoahHeap. > > Test: > - [x] hotspot_gc_shenandoah > - [x] nightly tests Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Fixed indentation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1964/files - new: https://git.openjdk.java.net/jdk/pull/1964/files/514aac66..7119186c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1964&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1964&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1964.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1964/head:pull/1964 PR: https://git.openjdk.java.net/jdk/pull/1964 From zgu at openjdk.java.net Thu Jan 21 13:56:29 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 21 Jan 2021 13:56:29 GMT Subject: RFR: 8260212: Shenandoah: resolve-only UpdateRefsMode is not used In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 08:31:36 GMT, Aleksey Shipilev wrote: > The only "use" is `ShenandoahMarkResolveRefsClosure`, which is unused itself. Looks good. ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2177 From rkennke at openjdk.java.net Thu Jan 21 13:58:47 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 21 Jan 2021 13:58:47 GMT Subject: RFR: 8255765: Shenandoah: Isolate concurrent, degenerated and full GC [v5] In-Reply-To: References: <9sUK197ZPOSEPLEDl8zKSqby-KMi9FryXnoctOdWmMc=.7b678df1-1c51-4bbf-b1a3-d8a8167a927d@github.com> Message-ID: On Thu, 21 Jan 2021 13:44:53 GMT, Zhengyu Gu wrote: >> The purpose of this patch is to isolate concurrent, degenerated and full gc implementation, so that, makes each GC implementation more straightforward and clean, and improves readability. >> >> Current implementation emphasis code sharing, e.g. degenerated GC reuses concurrent GC's ops. It was not a problem in the beginning, when they actually behave similarly. Since concurrent GC moved root processing into concurrent phases, code started to diverge, we started to put bandages to make the shared ops work for both concurrent and degenerated GC, that made code hard to read and error prone. >> >> The patch breaks up GCs into 3 (mainly just concurrent and degenerated GC, as full GC already standalone) easy to identify and understand classes (ShenandoahConcurrentGC, ShenandoahDegeneratedGC and ShenandoahMarkCompactGC), subclasses of ShenandoahGC class. >> >> The three GCs still keep vmop/entry/op paradigm, but encapsulate GC control flow inside their own classes, as ShenandoahMarkCompact GC already does. So that, concurrent and degenerated GC no longer share ops and op implementations no longer need to consider other GC modes, which results in simplifying implementation and improving readability. Code sharing is achieved via helper methods provided by ShenandoahHeap. >> >> Test: >> - [x] hotspot_gc_shenandoah >> - [x] nightly tests > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Fixed indentation Looks good! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1964 From shade at openjdk.java.net Thu Jan 21 16:48:56 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 21 Jan 2021 16:48:56 GMT Subject: RFR: 8255765: Shenandoah: Isolate concurrent, degenerated and full GC [v5] In-Reply-To: References: <9sUK197ZPOSEPLEDl8zKSqby-KMi9FryXnoctOdWmMc=.7b678df1-1c51-4bbf-b1a3-d8a8167a927d@github.com> Message-ID: On Thu, 21 Jan 2021 13:44:53 GMT, Zhengyu Gu wrote: >> The purpose of this patch is to isolate concurrent, degenerated and full gc implementation, so that, makes each GC implementation more straightforward and clean, and improves readability. >> >> Current implementation emphasis code sharing, e.g. degenerated GC reuses concurrent GC's ops. It was not a problem in the beginning, when they actually behave similarly. Since concurrent GC moved root processing into concurrent phases, code started to diverge, we started to put bandages to make the shared ops work for both concurrent and degenerated GC, that made code hard to read and error prone. >> >> The patch breaks up GCs into 3 (mainly just concurrent and degenerated GC, as full GC already standalone) easy to identify and understand classes (ShenandoahConcurrentGC, ShenandoahDegeneratedGC and ShenandoahMarkCompactGC), subclasses of ShenandoahGC class. >> >> The three GCs still keep vmop/entry/op paradigm, but encapsulate GC control flow inside their own classes, as ShenandoahMarkCompact GC already does. So that, concurrent and degenerated GC no longer share ops and op implementations no longer need to consider other GC modes, which results in simplifying implementation and improving readability. Code sharing is achieved via helper methods provided by ShenandoahHeap. >> >> Test: >> - [x] hotspot_gc_shenandoah >> - [x] nightly tests > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Fixed indentation Looks good. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1964 From zgu at openjdk.java.net Thu Jan 21 16:59:09 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 21 Jan 2021 16:59:09 GMT Subject: Integrated: 8255765: Shenandoah: Isolate concurrent, degenerated and full GC In-Reply-To: <9sUK197ZPOSEPLEDl8zKSqby-KMi9FryXnoctOdWmMc=.7b678df1-1c51-4bbf-b1a3-d8a8167a927d@github.com> References: <9sUK197ZPOSEPLEDl8zKSqby-KMi9FryXnoctOdWmMc=.7b678df1-1c51-4bbf-b1a3-d8a8167a927d@github.com> Message-ID: On Wed, 6 Jan 2021 16:45:03 GMT, Zhengyu Gu wrote: > The purpose of this patch is to isolate concurrent, degenerated and full gc implementation, so that, makes each GC implementation more straightforward and clean, and improves readability. > > Current implementation emphasis code sharing, e.g. degenerated GC reuses concurrent GC's ops. It was not a problem in the beginning, when they actually behave similarly. Since concurrent GC moved root processing into concurrent phases, code started to diverge, we started to put bandages to make the shared ops work for both concurrent and degenerated GC, that made code hard to read and error prone. > > The patch breaks up GCs into 3 (mainly just concurrent and degenerated GC, as full GC already standalone) easy to identify and understand classes (ShenandoahConcurrentGC, ShenandoahDegeneratedGC and ShenandoahMarkCompactGC), subclasses of ShenandoahGC class. > > The three GCs still keep vmop/entry/op paradigm, but encapsulate GC control flow inside their own classes, as ShenandoahMarkCompact GC already does. So that, concurrent and degenerated GC no longer share ops and op implementations no longer need to consider other GC modes, which results in simplifying implementation and improving readability. Code sharing is achieved via helper methods provided by ShenandoahHeap. > > Test: > - [x] hotspot_gc_shenandoah > - [x] nightly tests This pull request has now been integrated. Changeset: 34eb8b34 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/34eb8b34 Stats: 3218 lines in 20 files changed: 1802 ins; 1280 del; 136 mod 8255765: Shenandoah: Isolate concurrent, degenerated and full GC Reviewed-by: rkennke, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/1964 From kdnilsen at openjdk.java.net Thu Jan 21 18:39:20 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Thu, 21 Jan 2021 18:39:20 GMT Subject: RFR: Milestone 1 Message-ID: The objective of Milestone-1 is to demonstrate that certain heap regions can be designated as representing old-gen, card marking and remembered set implementation do not crash. Since the current implementation does not promote objects into old-gen space, much of the implementation of card marking and remembered set scanning is not exercised. The following simple test program was used to demonstrate execution: public class hello { public static void main(String args[]) { Node n = null; for (int count = 10000; count > 0; count--) { n = Node.upheaval(n); System.out.print(count); System.out.print(": Hello world: "); for (int i = 0; i < args.length; i++) { System.out.print(args[i]); System.out.print(" "); } System.out.print("[node value is " + n.value() + "]"); System.out.println(""); } } } import java.util.Random; public class Node { static private final int NeighborCount = 5; static private Random random = new Random(46); private int val; private Object field_o; private int[] field_ints; private Node [] neighbors; // Copy each neighbor of n into new node's neighbor array. Then overwrite // arbitrarily selected neighbor with newly allocated leaf node. public static Node upheaval(Node n) { int first_val = random.nextInt(); if (first_val < 0) first_val = -first_val; if (first_val < 0) first_val = 0; Node result = new Node(first_val); if (n != null) { for (int i = 0; i < NeighborCount; i++) result.neighbors[i] = n.neighbors[i]; } int second_val = random.nextInt(); if (second_val < 0) second_val = -second_val; if (second_val < 0) second_val = 0; int overwrite_index = first_val % NeighborCount; result.neighbors[overwrite_index] = new Node(second_val); return result; } public Node(int val) { this.val = val; this.field_o = new Object(); this.field_ints = new int[8]; this.field_ints[0] = 0xca; this.field_ints[1] = 0xfe; this.field_ints[2] = 0xba; this.field_ints[3] = 0xbe; this.field_ints[4] = 0xba; this.field_ints[5] = 0xad; this.field_ints[6] = 0xba; this.field_ints[7] = 0xbe; this.neighbors = new Node[NeighborCount]; } public int value() { return val; } } ------------- Commit messages: - Remove trailing whitespace - Initialize barrier set before it's used. - Allocate humongous objects in young gen - Fix includes in shenandoahCardTable file. - Public GenShen docs. - Fixed GC configuration report to JFR to reflect Shenandoah young collections. Changes: https://git.openjdk.java.net/shenandoah/pull/13/files Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=13&range=00 Stats: 789 lines in 7 files changed: 787 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/shenandoah/pull/13.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/13/head:pull/13 PR: https://git.openjdk.java.net/shenandoah/pull/13 From rkennke at openjdk.java.net Thu Jan 21 21:13:48 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 21 Jan 2021 21:13:48 GMT Subject: RFR: Milestone 1 In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 18:31:05 GMT, Kelvin Nilsen wrote: > The objective of Milestone-1 is to demonstrate that certain heap regions can be designated as representing old-gen, card marking and remembered set implementation do not crash. Since the current implementation does not promote objects into old-gen space, much of the implementation of card marking and remembered set scanning is not exercised. > > The following simple test program was used to demonstrate execution: > > public class hello { > public static void main(String args[]) { > Node n = null; > for (int count = 10000; count > 0; count--) { > n = Node.upheaval(n); > System.out.print(count); > System.out.print(": Hello world: "); > for (int i = 0; i < args.length; i++) { > System.out.print(args[i]); > System.out.print(" "); > } > System.out.print("[node value is " + n.value() + "]"); > System.out.println(""); > } > } > } > > import java.util.Random; > > public class Node { > static private final int NeighborCount = 5; > static private Random random = new Random(46); > > private int val; > private Object field_o; > > private int[] field_ints; > private Node [] neighbors; > > // Copy each neighbor of n into new node's neighbor array. Then overwrite > // arbitrarily selected neighbor with newly allocated leaf node. > public static Node upheaval(Node n) { > int first_val = random.nextInt(); > if (first_val < 0) first_val = -first_val; > if (first_val < 0) first_val = 0; > Node result = new Node(first_val); > if (n != null) { > for (int i = 0; i < NeighborCount; i++) > result.neighbors[i] = n.neighbors[i]; > } > int second_val = random.nextInt(); > if (second_val < 0) second_val = -second_val; > if (second_val < 0) second_val = 0; > int overwrite_index = first_val % NeighborCount; > result.neighbors[overwrite_index] = new Node(second_val); > return result; > } > > public Node(int val) { > this.val = val; > this.field_o = new Object(); > this.field_ints = new int[8]; > this.field_ints[0] = 0xca; > this.field_ints[1] = 0xfe; > this.field_ints[2] = 0xba; > this.field_ints[3] = 0xbe; > this.field_ints[4] = 0xba; > this.field_ints[5] = 0xad; > this.field_ints[6] = 0xba; > this.field_ints[7] = 0xbe; > this.neighbors = new Node[NeighborCount]; > } > > public int value() { > return val; > } > } Very nice! Only one question regarding what looks like a rogue include. Also, maybe the testprogram can be readily included as first jtreg test that exercises genshen when running make test TEST=hotspot_gc_shenandoah (even when it probably doesn't test anything except that it doesn't crash)? src/hotspot/share/gc/shenandoah/shenandoahCardTable.cpp line 26: > 24: > 25: #include "precompiled.hpp" > 26: #include "gc/shenandoah/shenandoahHeap.inline.hpp" What is this include used for? ------------- Changes requested by rkennke (Reviewer). PR: https://git.openjdk.java.net/shenandoah/pull/13 From kvn at openjdk.java.net Fri Jan 22 01:48:46 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 01:48:46 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 05:04:11 GMT, Igor Veresov wrote: >> This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> >> I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. >> >> Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Check legacy flags validity before deriving flag values for emulation mode. I would also suggest to do performance runs. Ask Eric for help. Changes are significant and may affect performance due to some typo. src/hotspot/share/compiler/compilerDefinitions.hpp line 234: > 232: static bool is_interpreter_only() { > 233: return Arguments::is_interpreter_only() || TieredStopAtLevel == CompLevel_none; > 234: } Can you move these functions after has_*() functions? They are used before. src/hotspot/share/compiler/compilerDefinitions.hpp line 179: > 177: } > 178: // Is the JVM in a configuration that permits only c2-compiled methods? > 179: // JVMCI compiler replaces C2. The comment `JVMCI compiler replaces C2.` should be removed or moved to `is_jvmci_compiler_only()` where it is make more sense. src/hotspot/share/compiler/compilerDefinitions.hpp line 171: > 169: } > 170: > 171: static bool is_c2_available() { For me `_available` suffix sounds similar to `has_`. May be `_enabled` is better. At least it is less confusing where it is called. src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp line 1414: > 1412: // use LD;DMB but stores use STLR. This can happen if C2 compiles > 1413: // the stores in one method and C1 compiles the loads in another. > 1414: if (!CompilerConfig::is_c1_or_interpreter_only_no_aot_or_jvmci()) { It is C1 code which should not be executed in -Xint. Why check `interpreter_only`? src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp line 54: > 52: ShenandoahBarrierSet::assembler()->cmpxchg_oop(masm->masm(), addr, cmpval, newval, /*acquire*/ true, /*release*/ true, /*is_cae*/ false, result); > 53: > 54: if (CompilerConfig::is_c1_or_interpreter_only_no_aot_or_jvmci()) { Again about `interpreter_only` check. src/hotspot/share/compiler/compilerDefinitions.hpp line 243: > 241: static bool is_c1_only_no_aot_or_jvmci() { > 242: return is_c1_only() && !is_aot() && !is_jvmci(); > 243: } These names are a little confusing: what about C2, why only no AOT and JVMCI. I understand that you want to check if JVMCI or AOT can install their compiled code. May be `is_c1_nmethods_only`, `is_c1_nmethods_or_interpreter_only` ? src/hotspot/share/oops/method.cpp line 1013: > 1011: return false; > 1012: if (comp_level == CompLevel_any) > 1013: return is_not_c1_compilable() && is_not_c2_compilable(); Was it bug before? src/hotspot/share/compiler/compilerDefinitions.cpp line 62: > 60: } > 61: } else if (strcmp(CompilationMode, "high-only") == 0) { > 62: if (!CompilerConfig::has_c2() && !CompilerConfig::is_jvmci_compiler()) { Is using `!is_c2_or_jvmci_compiler_available()` better here? All flags should be processed at this point. And we could have some `TieredStopAtLevel` flags. It looks like you have cross dependency between CompilerConfig and CompilationModeFlag which make using `is_c2_or_jvmci_compiler_available()` impossible here. src/hotspot/share/compiler/compilerDefinitions.cpp line 84: > 82: } else if (CompilerConfig::is_c2_or_jvmci_compiler_only()) { > 83: _mode = Mode::HIGH_ONLY; > 84: } else if (CompilerConfig::is_jvmci_compiler() && !TieredCompilation) { Should you check `CompilerConfig::is_tiered()` instead of `TieredCompilation` flag? ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Fri Jan 22 01:48:49 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 01:48:49 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 23:06:19 GMT, Igor Veresov wrote: >> This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> >> I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. >> >> Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Fix another s390 compilation failure src/hotspot/share/aot/aotCodeHeap.cpp line 194: > 192: // AOT libs are loaded before heap initialized so shift values are not set. > 193: // It is okay since ObjectAlignmentInBytes flag which defines shifts value is set before AOT libs are loaded. > 194: // Set shifts value based on first AOT library config. Why this code is removed? src/hotspot/share/compiler/compileBroker.cpp line 972: > 970: > 971: // Initialize the compilation queue > 972: if (_c2_count > 0) { Is ZERO treated as `is_interpreter_only()` ? How this change works with ZERO? src/hotspot/share/runtime/vmStructs.cpp line 296: > 294: JVMTI_ONLY(nonstatic_field(MethodCounters, _number_of_breakpoints, u2)) \ > 295: nonstatic_field(MethodCounters, _invocation_counter, InvocationCounter) \ > 296: nonstatic_field(MethodCounters, _backedge_counter, InvocationCounter) \ You need to fix SA agent: https://github.com/openjdk/jdk/blob/master/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodCounters.java#L52 src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 229: > 227: JVMTI_ONLY(nonstatic_field(MethodCounters, _number_of_breakpoints, u2)) \ > 228: nonstatic_field(MethodCounters, _invocation_counter, InvocationCounter) \ > 229: nonstatic_field(MethodCounters, _backedge_counter, InvocationCounter) \ I don't see Java JVMCI changes. Do you need them? test/hotspot/jtreg/TEST.quick-groups line 1787: > 1785: vmTestbase/jit/t/t112/t112.java \ > 1786: vmTestbase/jit/t/t113/t113.java \ > 1787: vmTestbase/jit/verifier/VerifyInitLocal/VerifyInitLocal.java \ Why this test removed? ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From shade at openjdk.java.net Fri Jan 22 11:43:54 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 22 Jan 2021 11:43:54 GMT Subject: Integrated: 8260212: Shenandoah: resolve-only UpdateRefsMode is not used In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 08:31:36 GMT, Aleksey Shipilev wrote: > The only "use" is `ShenandoahMarkResolveRefsClosure`, which is unused itself. This pull request has now been integrated. Changeset: bfac3fb5 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/bfac3fb5 Stats: 18 lines in 2 files changed: 0 ins; 18 del; 0 mod 8260212: Shenandoah: resolve-only UpdateRefsMode is not used Reviewed-by: rkennke, zgu ------------- PR: https://git.openjdk.java.net/jdk/pull/2177 From shade at openjdk.java.net Fri Jan 22 12:16:10 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 22 Jan 2021 12:16:10 GMT Subject: RFR: 8260106: Shenandoah: simplify maybe_update_with_forwarded and related code [v3] In-Reply-To: References: Message-ID: > We have a block in `ShenandoahHeap::maybe_update_with_forwarded` that is irrelevant after JDK-8231086. Additionally, "resolve and update" paths are really only used by STW GCs, and thus do not require atomic updates. This leads to considerable simplifications in the code, and improves performance on the common paths (especially in fastdebug builds that drop many irrelevant asserts). > > Additional testing: > - [x] `hotspot_gc_shenandoah` > - [x] `tier1` with Shenandoah > - [x] `tier2` with Shenandoah Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Simplify further after RESOLVE removal - Merge branch 'master' into JDK-8260106-shenandoah-simplify-updates - Rename maybe to atomic - Touch up comments - 8260106: Shenandoah: simplify maybe_update_with_forwarded and related code ------------- Changes: https://git.openjdk.java.net/jdk/pull/2166/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2166&range=02 Stats: 159 lines in 5 files changed: 19 ins; 84 del; 56 mod Patch: https://git.openjdk.java.net/jdk/pull/2166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2166/head:pull/2166 PR: https://git.openjdk.java.net/jdk/pull/2166 From shade at openjdk.java.net Fri Jan 22 12:16:10 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 22 Jan 2021 12:16:10 GMT Subject: RFR: 8260106: Shenandoah: simplify maybe_update_with_forwarded and related code [v2] In-Reply-To: References: <6kABGv_phymIASILTHYVqGaQf6Lu7tgqj4wQYibNYaA=.12ef2e99-9d24-4a15-be74-aaf468cd0ca5@github.com> Message-ID: On Thu, 21 Jan 2021 08:59:07 GMT, Roman Kennke wrote: >> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: >> >> - Rename maybe to atomic >> - Touch up comments > > Looks good! Thanks! I updated the patch a bit after `RESOLVE` mode removal. I think `NO_UPDATE` and `STW_UPDATE` reads better. This also highlights that STW closures are really doing non-CAS updates. ------------- PR: https://git.openjdk.java.net/jdk/pull/2166 From kbarrett at openjdk.java.net Fri Jan 22 13:17:05 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 22 Jan 2021 13:17:05 GMT Subject: RFR: 8256814: WeakProcessorPhases may be redundant [v4] In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 10:09:51 GMT, Stefan Karlsson wrote: >> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Merge branch 'master' into wpp4 >> - update copyrights >> - remove type aliases for OopStorageSet::WeakId >> - Merge branch 'master' into wpp4 >> - stefank review >> - Remove WeakProcessorPhase, adding scoped enum categories to OopStorageSet. > > I think this looks good. I have a few comments that I would like to get addressed, but they are not blockers if you want to proceed with what you have. Thanks @stefank , @tschatzl , @rkennke for reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/1862 From kbarrett at openjdk.java.net Fri Jan 22 13:17:05 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 22 Jan 2021 13:17:05 GMT Subject: RFR: 8256814: WeakProcessorPhases may be redundant [v4] In-Reply-To: References: Message-ID: > Please review this change which eliminates the WeakProcessorPhase class. > > The OopStorageSet class is changed to provide scoped enums for the different > categories: StrongId, WeakId, and Id (for the union of strong and weak). > An accessor is provided for obtaining the storage corresponding to a > category value. > > Various other enumerator ranges, array sizes and indices, and iterations are > derived directly from the corresponding OopStorageSet category's enum range. > > Iteration over a category of enumerators can be done via EnumIterator. The > iteration over storage objects makes use of that enum iteration, rather than > having a bespoke implementation. Some use-cases need iteration of the > enumerators, with storage lookup from the enumerator; other use-cases just > need the storage objects. > > Testing: > mach5 tier1-6 > Local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' into wpp4 - update copyrights - remove type aliases for OopStorageSet::WeakId - Merge branch 'master' into wpp4 - stefank review - Remove WeakProcessorPhase, adding scoped enum categories to OopStorageSet. ------------- Changes: https://git.openjdk.java.net/jdk/pull/1862/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1862&range=03 Stats: 1052 lines in 25 files changed: 398 ins; 465 del; 189 mod Patch: https://git.openjdk.java.net/jdk/pull/1862.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1862/head:pull/1862 PR: https://git.openjdk.java.net/jdk/pull/1862 From kbarrett at openjdk.java.net Fri Jan 22 13:17:08 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 22 Jan 2021 13:17:08 GMT Subject: Integrated: 8256814: WeakProcessorPhases may be redundant In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 04:59:28 GMT, Kim Barrett wrote: > Please review this change which eliminates the WeakProcessorPhase class. > > The OopStorageSet class is changed to provide scoped enums for the different > categories: StrongId, WeakId, and Id (for the union of strong and weak). > An accessor is provided for obtaining the storage corresponding to a > category value. > > Various other enumerator ranges, array sizes and indices, and iterations are > derived directly from the corresponding OopStorageSet category's enum range. > > Iteration over a category of enumerators can be done via EnumIterator. The > iteration over storage objects makes use of that enum iteration, rather than > having a bespoke implementation. Some use-cases need iteration of the > enumerators, with storage lookup from the enumerator; other use-cases just > need the storage objects. > > Testing: > mach5 tier1-6 > Local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC This pull request has now been integrated. Changeset: 7ed8ba1c Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/7ed8ba1c Stats: 1052 lines in 25 files changed: 398 ins; 465 del; 189 mod 8256814: WeakProcessorPhases may be redundant Remove WeakProcessorPhase, adding scoped enum categories to OopStorageSet. Reviewed-by: stefank, tschatzl, rkennke ------------- PR: https://git.openjdk.java.net/jdk/pull/1862 From iveresov at openjdk.java.net Fri Jan 22 15:22:50 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 15:22:50 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 19:51:11 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Check legacy flags validity before deriving flag values for emulation mode. > > src/hotspot/share/compiler/compilerDefinitions.hpp line 234: > >> 232: static bool is_interpreter_only() { >> 233: return Arguments::is_interpreter_only() || TieredStopAtLevel == CompLevel_none; >> 234: } > > Can you move these functions after has_*() functions? They are used before. Right now has_() functions are defined before uses. Do you want them to be after the uses? Please confirm. > src/hotspot/share/compiler/compilerDefinitions.hpp line 179: > >> 177: } >> 178: // Is the JVM in a configuration that permits only c2-compiled methods? >> 179: // JVMCI compiler replaces C2. > > The comment `JVMCI compiler replaces C2.` should be removed or moved to `is_jvmci_compiler_only()` where it is make more sense. I removed the comment, it does seem to be out of context. I'm not sure why I put it there. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From rkennke at openjdk.java.net Fri Jan 22 15:53:47 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 22 Jan 2021 15:53:47 GMT Subject: RFR: 8260106: Shenandoah: simplify maybe_update_with_forwarded and related code [v3] In-Reply-To: References: Message-ID: <9fHyPXjbBbqKJlZJxNyeeLytjC6ASp87u1i8Pf1cT4s=.eb0bee65-eca2-4513-b0d0-1ce174cf5b7e@github.com> On Fri, 22 Jan 2021 12:16:10 GMT, Aleksey Shipilev wrote: >> We have a block in `ShenandoahHeap::maybe_update_with_forwarded` that is irrelevant after JDK-8231086. Additionally, "resolve and update" paths are really only used by STW GCs, and thus do not require atomic updates. This leads to considerable simplifications in the code, and improves performance on the common paths (especially in fastdebug builds that drop many irrelevant asserts). >> >> Additional testing: >> - [x] `hotspot_gc_shenandoah` >> - [x] `tier1` with Shenandoah >> - [x] `tier2` with Shenandoah > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Simplify further after RESOLVE removal > - Merge branch 'master' into JDK-8260106-shenandoah-simplify-updates > - Rename maybe to atomic > - Touch up comments > - 8260106: Shenandoah: simplify maybe_update_with_forwarded and related code Looks good to me! Thanks! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2166 From shade at openjdk.java.net Fri Jan 22 16:27:59 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 22 Jan 2021 16:27:59 GMT Subject: RFR: 8260106: Shenandoah: simplify maybe_update_with_forwarded and related code [v4] In-Reply-To: References: Message-ID: > We have a block in `ShenandoahHeap::maybe_update_with_forwarded` that is irrelevant after JDK-8231086. Additionally, "resolve and update" paths are really only used by STW GCs, and thus do not require atomic updates. This leads to considerable simplifications in the code, and improves performance on the common paths (especially in fastdebug builds that drop many irrelevant asserts). > > Additional testing: > - [x] `hotspot_gc_shenandoah` > - [x] `tier1` with Shenandoah > - [x] `tier2` with Shenandoah Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: - Simplify ShenandoahUpdateHeapRefsTask - Fix up generic update references too, introduce CONC_UPDATE ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2166/files - new: https://git.openjdk.java.net/jdk/pull/2166/files/edcab593..a479e7b7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2166&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2166&range=02-03 Stats: 90 lines in 12 files changed: 64 ins; 5 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/2166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2166/head:pull/2166 PR: https://git.openjdk.java.net/jdk/pull/2166 From shade at openjdk.java.net Fri Jan 22 16:28:00 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 22 Jan 2021 16:28:00 GMT Subject: RFR: 8260106: Shenandoah: simplify maybe_update_with_forwarded and related code [v3] In-Reply-To: <9fHyPXjbBbqKJlZJxNyeeLytjC6ASp87u1i8Pf1cT4s=.eb0bee65-eca2-4513-b0d0-1ce174cf5b7e@github.com> References: <9fHyPXjbBbqKJlZJxNyeeLytjC6ASp87u1i8Pf1cT4s=.eb0bee65-eca2-4513-b0d0-1ce174cf5b7e@github.com> Message-ID: On Fri, 22 Jan 2021 15:51:06 GMT, Roman Kennke wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: >> >> - Simplify further after RESOLVE removal >> - Merge branch 'master' into JDK-8260106-shenandoah-simplify-updates >> - Rename maybe to atomic >> - Touch up comments >> - 8260106: Shenandoah: simplify maybe_update_with_forwarded and related code > > Looks good to me! Thanks! This kinda keeps creeping: I just realized we need to sweep in the "normal" update references in the same thing. I'll make this a draft and keep working on it. ------------- PR: https://git.openjdk.java.net/jdk/pull/2166 From iveresov at openjdk.java.net Fri Jan 22 17:02:48 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 17:02:48 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 20:17:48 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Check legacy flags validity before deriving flag values for emulation mode. > > src/hotspot/share/compiler/compilerDefinitions.hpp line 171: > >> 169: } >> 170: >> 171: static bool is_c2_available() { > > For me `_available` suffix sounds similar to `has_`. May be `_enabled` is better. At least it is less confusing where it is called. Ok, I'll do that. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 17:09:52 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 17:09:52 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: <-XgAzg034eEEPCuR342rrb4r6X-2yLRxGbr2QJgXoLw=.c1926204-ba05-4b70-891d-fd1765cc9778@github.com> On Wed, 20 Jan 2021 20:28:34 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Check legacy flags validity before deriving flag values for emulation mode. > > src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp line 1414: > >> 1412: // use LD;DMB but stores use STLR. This can happen if C2 compiles >> 1413: // the stores in one method and C1 compiles the loads in another. >> 1414: if (!CompilerConfig::is_c1_or_interpreter_only_no_aot_or_jvmci()) { > > It is C1 code which should not be executed in -Xint. Why check `interpreter_only`? Good point, I'll fix that. > src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp line 54: > >> 52: ShenandoahBarrierSet::assembler()->cmpxchg_oop(masm->masm(), addr, cmpval, newval, /*acquire*/ true, /*release*/ true, /*is_cae*/ false, result); >> 53: >> 54: if (CompilerConfig::is_c1_or_interpreter_only_no_aot_or_jvmci()) { > > Again about `interpreter_only` check. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 17:16:45 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 17:16:45 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 20:36:35 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix another s390 compilation failure > > src/hotspot/share/aot/aotCodeHeap.cpp line 194: > >> 192: // AOT libs are loaded before heap initialized so shift values are not set. >> 193: // It is okay since ObjectAlignmentInBytes flag which defines shifts value is set before AOT libs are loaded. >> 194: // Set shifts value based on first AOT library config. > > Why this code is removed? It's always running with the tiered policy now. Prior to this change if you attempted to run an AOT library with tiered-style profiling compiled in with the non-tiered policy it wouldn't work correctly. That's why we had this check. Now tiered is the only policy, so it will work correctly whether you have the AOT code with profiling or not. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 17:23:47 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 17:23:47 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 20:52:31 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Check legacy flags validity before deriving flag values for emulation mode. > > src/hotspot/share/compiler/compilerDefinitions.hpp line 243: > >> 241: static bool is_c1_only_no_aot_or_jvmci() { >> 242: return is_c1_only() && !is_aot() && !is_jvmci(); >> 243: } > > These names are a little confusing: what about C2, why only no AOT and JVMCI. I understand that you want to check if JVMCI or AOT can install their compiled code. > May be `is_c1_nmethods_only`, `is_c1_nmethods_or_interpreter_only` ? I guess it's a matter of naming convention. What I tried to make the CompilerConfig API about is to check if compilers are present/enabled and in which combination. Of course presence of a compiler implies that we're going to see nmethod produced by it. I'd like to keep the current naming if it's not a huge eyesore for you. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 17:35:52 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 17:35:52 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 00:43:29 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Check legacy flags validity before deriving flag values for emulation mode. > > src/hotspot/share/oops/method.cpp line 1013: > >> 1011: return false; >> 1012: if (comp_level == CompLevel_any) >> 1013: return is_not_c1_compilable() && is_not_c2_compilable(); > > Was it bug before? Yup. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 17:35:48 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 17:35:48 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 00:24:34 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix another s390 compilation failure > > src/hotspot/share/compiler/compileBroker.cpp line 972: > >> 970: >> 971: // Initialize the compilation queue >> 972: if (_c2_count > 0) { > > Is ZERO treated as `is_interpreter_only()` ? How this change works with ZERO? I forgot why I removed that. Let me put it back and run it through testing again. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 17:55:47 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 17:55:47 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 00:56:16 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix another s390 compilation failure > > src/hotspot/share/runtime/vmStructs.cpp line 296: > >> 294: JVMTI_ONLY(nonstatic_field(MethodCounters, _number_of_breakpoints, u2)) \ >> 295: nonstatic_field(MethodCounters, _invocation_counter, InvocationCounter) \ >> 296: nonstatic_field(MethodCounters, _backedge_counter, InvocationCounter) \ > > You need to fix SA agent: > https://github.com/openjdk/jdk/blob/master/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodCounters.java#L52 Good point. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Fri Jan 22 18:22:08 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 18:22:08 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 15:19:39 GMT, Igor Veresov wrote: >> src/hotspot/share/compiler/compilerDefinitions.hpp line 234: >> >>> 232: static bool is_interpreter_only() { >>> 233: return Arguments::is_interpreter_only() || TieredStopAtLevel == CompLevel_none; >>> 234: } >> >> Can you move these functions after has_*() functions? They are used before. > > Right now has_() functions are defined before uses. Do you want them to be after the uses? Please confirm. Don't touch has_() - they are in correct place. I am asking only to move these 4 is_() functions between has_() and is_c1_only() function. >> src/hotspot/share/compiler/compilerDefinitions.hpp line 243: >> >>> 241: static bool is_c1_only_no_aot_or_jvmci() { >>> 242: return is_c1_only() && !is_aot() && !is_jvmci(); >>> 243: } >> >> These names are a little confusing: what about C2, why only no AOT and JVMCI. I understand that you want to check if JVMCI or AOT can install their compiled code. >> May be `is_c1_nmethods_only`, `is_c1_nmethods_or_interpreter_only` ? > > I guess it's a matter of naming convention. What I tried to make the CompilerConfig API about is to check if compilers are present/enabled and in which combination. Of course presence of a compiler implies that we're going to see nmethod produced by it. I'd like to keep the current naming if it's not a huge eyesore for you. Hmm, may be we don't need these funxctions. Seems is_c1_only() will be true only when JVMCI is off. Right? We can also reinforce it to exclude AOT too. And AOT and JVMCI are disabled with -Xint. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 18:22:09 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 18:22:09 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 01:11:33 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix another s390 compilation failure > > src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 229: > >> 227: JVMTI_ONLY(nonstatic_field(MethodCounters, _number_of_breakpoints, u2)) \ >> 228: nonstatic_field(MethodCounters, _invocation_counter, InvocationCounter) \ >> 229: nonstatic_field(MethodCounters, _backedge_counter, InvocationCounter) \ > > I don't see Java JVMCI changes. Do you need them? I haven't found any uses of it. > test/hotspot/jtreg/TEST.quick-groups line 1787: > >> 1785: vmTestbase/jit/t/t112/t112.java \ >> 1786: vmTestbase/jit/t/t113/t113.java \ >> 1787: vmTestbase/jit/verifier/VerifyInitLocal/VerifyInitLocal.java \ > > Why this test removed? It was an odd test that check if the -XX:+PrintTieredEvents flag didn't work with -XX:-TieredCompilation. Since now it always works that test doesn't make much sense anymore. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Fri Jan 22 18:22:10 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 18:22:10 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: <3tY1BN0Q7o5K4cFcRH_KRk8djNOlMOpzU9yY3XpeaRc=.8128e81c-74b0-43c0-b96b-2eeee24d660d@github.com> On Fri, 22 Jan 2021 17:14:15 GMT, Igor Veresov wrote: >> src/hotspot/share/aot/aotCodeHeap.cpp line 194: >> >>> 192: // AOT libs are loaded before heap initialized so shift values are not set. >>> 193: // It is okay since ObjectAlignmentInBytes flag which defines shifts value is set before AOT libs are loaded. >>> 194: // Set shifts value based on first AOT library config. >> >> Why this code is removed? > > It's always running with the tiered policy now. Prior to this change if you attempted to run an AOT library with tiered-style profiling compiled in with the non-tiered policy it wouldn't work correctly. That's why we had this check. Now tiered is the only policy, so it will work correctly whether you have the AOT code with profiling or not. Okay. Got it ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 18:22:10 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 18:22:10 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 17:51:36 GMT, Vladimir Kozlov wrote: >> Right now has_() functions are defined before uses. Do you want them to be after the uses? Please confirm. > > Don't touch has_() - they are in correct place. I am asking only to move these 4 is_() functions between has_() and is_c1_only() function. I understand what you mean now. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 18:22:11 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 18:22:11 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 01:25:25 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Check legacy flags validity before deriving flag values for emulation mode. > > src/hotspot/share/compiler/compilerDefinitions.cpp line 62: > >> 60: } >> 61: } else if (strcmp(CompilationMode, "high-only") == 0) { >> 62: if (!CompilerConfig::has_c2() && !CompilerConfig::is_jvmci_compiler()) { > > Is using `!is_c2_or_jvmci_compiler_available()` better here? All flags should be processed at this point. And we could have some `TieredStopAtLevel` flags. > It looks like you have cross dependency between CompilerConfig and CompilationModeFlag which make using `is_c2_or_jvmci_compiler_available()` impossible here. Yes, there is an unfortunate cross dependency. It would probably work fine since ```_mode``` is initialized to ```NORMAL``` before parsing the flag. But I wanted to not use any function that would depend on the value of the ```_mode``` during parsing. It could create trouble in the future. I'll put more comments about that. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 18:29:48 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 18:29:48 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 18:04:54 GMT, Vladimir Kozlov wrote: >> I guess it's a matter of naming convention. What I tried to make the CompilerConfig API about is to check if compilers are present/enabled and in which combination. Of course presence of a compiler implies that we're going to see nmethod produced by it. I'd like to keep the current naming if it's not a huge eyesore for you. > > Hmm, may be we don't need these funxctions. > Seems is_c1_only() will be true only when JVMCI is off. Right? We can also reinforce it to exclude AOT too. > And AOT and JVMCI are disabled with -Xint. It's not so easy. You can have AOT or JVMCI enabled with -Xint. JVMCI code installs can be initiated not only as a result of method going through the compiler broker. Remember that you can run Graal in "host" mode, where it is a normal C1/C2 system (or may be just an interpreter); Truffle can work in a mode like that. And you can totally run with AOT and interpreter (without any JIT). ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 20:02:55 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 20:02:55 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 01:37:53 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Check legacy flags validity before deriving flag values for emulation mode. > > src/hotspot/share/compiler/compilerDefinitions.cpp line 84: > >> 82: } else if (CompilerConfig::is_c2_or_jvmci_compiler_only()) { >> 83: _mode = Mode::HIGH_ONLY; >> 84: } else if (CompilerConfig::is_jvmci_compiler() && !TieredCompilation) { > > Should you check `CompilerConfig::is_tiered()` instead of `TieredCompilation` flag? I wanted to be explicit about what's happening here. I'd like it to be obvious that the we're switching to ```HIGH_ONLY_QUICK_INTERNAL``` mode as a result of the user specifying -XX:-TieredCompilation on the command line. There is a bug on this line however. I should be checking if c1 is present and enabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Fri Jan 22 20:07:51 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 20:07:51 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 18:15:40 GMT, Igor Veresov wrote: >> src/hotspot/share/compiler/compilerDefinitions.cpp line 62: >> >>> 60: } >>> 61: } else if (strcmp(CompilationMode, "high-only") == 0) { >>> 62: if (!CompilerConfig::has_c2() && !CompilerConfig::is_jvmci_compiler()) { >> >> Is using `!is_c2_or_jvmci_compiler_available()` better here? All flags should be processed at this point. And we could have some `TieredStopAtLevel` flags. >> It looks like you have cross dependency between CompilerConfig and CompilationModeFlag which make using `is_c2_or_jvmci_compiler_available()` impossible here. > > Yes, there is an unfortunate cross dependency. It would probably work fine since ```_mode``` is initialized to ```NORMAL``` before parsing the flag. But I wanted to not use any function that would depend on the value of the ```_mode``` during parsing. It could create trouble in the future. I'll put more comments about that. okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Fri Jan 22 20:10:53 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 20:10:53 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 18:26:43 GMT, Igor Veresov wrote: >> Hmm, may be we don't need these funxctions. >> Seems is_c1_only() will be true only when JVMCI is off. Right? We can also reinforce it to exclude AOT too. >> And AOT and JVMCI are disabled with -Xint. > > It's not so easy. You can have AOT or JVMCI enabled with -Xint. JVMCI code installs can be initiated not only as a result of method going through the compiler broker. Remember that you can run Graal in "host" mode, where it is a normal C1/C2 system (or may be just an interpreter); Truffle can work in a mode like that. And you can totally run with AOT and interpreter (without any JIT). I don't think so: > java -Xint -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -version Java HotSpot(TM) 64-Bit Server VM warning: JVMCI Compiler disabled due to -Xint. > java -Xint -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -XX:+PrintAOT -version Java HotSpot(TM) 64-Bit Server VM warning: -Xint is not compatible with AOT (switching AOT off) ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Fri Jan 22 20:14:49 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 20:14:49 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 19:50:48 GMT, Igor Veresov wrote: >> src/hotspot/share/compiler/compilerDefinitions.cpp line 84: >> >>> 82: } else if (CompilerConfig::is_c2_or_jvmci_compiler_only()) { >>> 83: _mode = Mode::HIGH_ONLY; >>> 84: } else if (CompilerConfig::is_jvmci_compiler() && !TieredCompilation) { >> >> Should you check `CompilerConfig::is_tiered()` instead of `TieredCompilation` flag? > > I wanted to be explicit about what's happening here. I'd like it to be obvious that the we're switching to ```HIGH_ONLY_QUICK_INTERNAL``` mode as a result of the user specifying -XX:-TieredCompilation on the command line. > > There is a bug on this line however. I should be checking if c1 is present and enabled. okay ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 20:19:49 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 20:19:49 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 20:08:17 GMT, Vladimir Kozlov wrote: >> It's not so easy. You can have AOT or JVMCI enabled with -Xint. JVMCI code installs can be initiated not only as a result of method going through the compiler broker. Remember that you can run Graal in "host" mode, where it is a normal C1/C2 system (or may be just an interpreter); Truffle can work in a mode like that. And you can totally run with AOT and interpreter (without any JIT). > > I don't think so: >> java -Xint -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -version > Java HotSpot(TM) 64-Bit Server VM warning: JVMCI Compiler disabled due to -Xint. > >> java -Xint -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -XX:+PrintAOT -version > Java HotSpot(TM) 64-Bit Server VM warning: -Xint is not compatible with AOT (switching AOT off) You're right. Perhaps I was overly defensive. It doesn't hurt though, less potential surprises in the future (as you correctly noticed those are used to make sure there are no nmethods produced by any other compiler but C1). Also you still can have a C1 and AOT combination. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Fri Jan 22 20:31:50 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 20:31:50 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 20:17:24 GMT, Igor Veresov wrote: >> I don't think so: >>> java -Xint -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -version >> Java HotSpot(TM) 64-Bit Server VM warning: JVMCI Compiler disabled due to -Xint. >> >>> java -Xint -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -XX:+PrintAOT -version >> Java HotSpot(TM) 64-Bit Server VM warning: -Xint is not compatible with AOT (switching AOT off) > > You're right. Perhaps I was overly defensive. It doesn't hurt though, less potential surprises in the future (as you correctly noticed those are used to make sure there are no nmethods produced by any other compiler but C1). > Also you still can have a C1 and AOT combination. Yes. You can have C1 in combination with AOT and JVMCI (hosted). I looked on use cases for these 4 methods and it seems it will be hard to only use one. Okay. Leave them as it is. May be add comments to explain why you needs these variants. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iwalulya at openjdk.java.net Sat Jan 23 08:40:41 2021 From: iwalulya at openjdk.java.net (Ivan Walulya) Date: Sat, 23 Jan 2021 08:40:41 GMT Subject: RFR: 8258742: Move PtrQueue reset to PtrQueueSet subclasses In-Reply-To: References: Message-ID: <7TEY2FCK1gA0vAtL15lQChhXgsxgF7qabipKcXv-n-8=.8431f565-19eb-4528-ba16-e7b9cc1fbcdb@github.com> On Sun, 17 Jan 2021 13:17:20 GMT, Kim Barrett wrote: > Please remove this change to the PtrQueue hierarchy, changing queue reset > from an intrinsic operation of the queue to an operation the qset performs > on a queue. This is another piece of the refactoring being done under > JDK-8258251, separated out for easier review. > > After the refactoring of queue reset, PtrQueue::is_empty and PtrQueue::size > are no longer used, so are removed. Further, PtrQueue::{set_}index_in_bytes > are removed, directly using _index instead. > > A less obvious part of the change is in the G1 remark task and Shenandoah > final marking task. The threads walk performed by these no longer directly > processes the partial per-thread SATB buffers. Instead they just flush the > queues for later completed buffer processing. > > Testing: > mach5 tier1 > local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC Looks good! ------------- Marked as reviewed by iwalulya (Committer). PR: https://git.openjdk.java.net/jdk/pull/2115 From kbarrett at openjdk.java.net Sat Jan 23 19:32:40 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 23 Jan 2021 19:32:40 GMT Subject: RFR: 8258742: Move PtrQueue reset to PtrQueueSet subclasses In-Reply-To: <1dgRRDTcWGLGFijLRvA01DMsmGoQMoFZM8-1Z5VrWQ4=.96f80cf3-136b-4a86-bf9e-f9db626f3979@github.com> References: <1dgRRDTcWGLGFijLRvA01DMsmGoQMoFZM8-1Z5VrWQ4=.96f80cf3-136b-4a86-bf9e-f9db626f3979@github.com> Message-ID: On Mon, 18 Jan 2021 10:35:14 GMT, Thomas Schatzl wrote: >> Please review this change to the PtrQueue hierarchy, changing queue reset >> from an intrinsic operation of the queue to an operation the qset performs >> on a queue. This is another piece of the refactoring being done under >> JDK-8258251, separated out for easier review. >> >> After the refactoring of queue reset, PtrQueue::is_empty and PtrQueue::size >> are no longer used, so are removed. Further, PtrQueue::{set_}index_in_bytes >> are removed, directly using _index instead. >> >> A less obvious part of the change is in the G1 remark task and Shenandoah >> final marking task. The threads walk performed by these no longer directly >> processes the partial per-thread SATB buffers. Instead they just flush the >> queues for later completed buffer processing. >> >> Testing: >> mach5 tier1 >> local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC > > Lgtm. Thanks @tschatzl and @walulyai for reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/2115 From kbarrett at openjdk.java.net Sat Jan 23 19:51:54 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 23 Jan 2021 19:51:54 GMT Subject: Integrated: 8258742: Move PtrQueue reset to PtrQueueSet subclasses In-Reply-To: References: Message-ID: On Sun, 17 Jan 2021 13:17:20 GMT, Kim Barrett wrote: > Please review this change to the PtrQueue hierarchy, changing queue reset > from an intrinsic operation of the queue to an operation the qset performs > on a queue. This is another piece of the refactoring being done under > JDK-8258251, separated out for easier review. > > After the refactoring of queue reset, PtrQueue::is_empty and PtrQueue::size > are no longer used, so are removed. Further, PtrQueue::{set_}index_in_bytes > are removed, directly using _index instead. > > A less obvious part of the change is in the G1 remark task and Shenandoah > final marking task. The threads walk performed by these no longer directly > processes the partial per-thread SATB buffers. Instead they just flush the > queues for later completed buffer processing. > > Testing: > mach5 tier1 > local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC This pull request has now been integrated. Changeset: 6c4c96fa Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/6c4c96fa Stats: 89 lines in 9 files changed: 17 ins; 45 del; 27 mod 8258742: Move PtrQueue reset to PtrQueueSet subclasses Reviewed-by: tschatzl, iwalulya ------------- PR: https://git.openjdk.java.net/jdk/pull/2115 From kbarrett at openjdk.java.net Sat Jan 23 19:51:54 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 23 Jan 2021 19:51:54 GMT Subject: RFR: 8258742: Move PtrQueue reset to PtrQueueSet subclasses [v2] In-Reply-To: References: Message-ID: > Please review this change to the PtrQueue hierarchy, changing queue reset > from an intrinsic operation of the queue to an operation the qset performs > on a queue. This is another piece of the refactoring being done under > JDK-8258251, separated out for easier review. > > After the refactoring of queue reset, PtrQueue::is_empty and PtrQueue::size > are no longer used, so are removed. Further, PtrQueue::{set_}index_in_bytes > are removed, directly using _index instead. > > A less obvious part of the change is in the G1 remark task and Shenandoah > final marking task. The threads walk performed by these no longer directly > processes the partial per-thread SATB buffers. Instead they just flush the > queues for later completed buffer processing. > > Testing: > mach5 tier1 > local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' into move_reset - update shenandoah - remove pq index_in_bytes - remove pq size - remove pq is_empty - move reset ------------- Changes: https://git.openjdk.java.net/jdk/pull/2115/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2115&range=01 Stats: 89 lines in 9 files changed: 17 ins; 45 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/2115.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2115/head:pull/2115 PR: https://git.openjdk.java.net/jdk/pull/2115 From zgu at openjdk.java.net Sun Jan 24 01:34:58 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Sun, 24 Jan 2021 01:34:58 GMT Subject: RFR: 8256298: Shenandoah: Enable concurrent stack processing Message-ID: Please review this patch that enables concurrent stack processing for Shenandoah GC. After this patch, all root processing is done concurrently for concurrent GC. Test: - [x] hotspot_gc_shenandoah Linux x86_64 and x86_32 - [x] Nightly - [x] tier1 with -XX:+UseShenandoahGC on Linux x86_32 ------------- Commit messages: - Merge master - Merge branch 'JDK-8255765-isolate-gcs' into JDK-8256298-conc-stack-proc - Fixed indentation - More from Aleksey's review - cleanup - fix styles and cleanup - Removed unnecessary includes - Merge - Merge branch 'JDK-8255765-isolate-gcs' into JDK-8256298-conc-stack-proc - Merge branch 'master' into JDK-8255765-isolate-gcs - ... and 121 more: https://git.openjdk.java.net/jdk/compare/34eb8b34...4fd486b5 Changes: https://git.openjdk.java.net/jdk/pull/2185/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2185&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256298 Stats: 649 lines in 19 files changed: 466 ins; 129 del; 54 mod Patch: https://git.openjdk.java.net/jdk/pull/2185.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2185/head:pull/2185 PR: https://git.openjdk.java.net/jdk/pull/2185 From zgu at openjdk.java.net Sun Jan 24 01:46:56 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Sun, 24 Jan 2021 01:46:56 GMT Subject: RFR: 8256298: Shenandoah: Enable concurrent stack processing [v2] In-Reply-To: References: Message-ID: > Please review this patch that enables concurrent stack processing for Shenandoah GC. > > After this patch, all root processing is done concurrently for concurrent GC. > > Test: > - [x] hotspot_gc_shenandoah Linux x86_64 and x86_32 > - [x] Nightly > - [x] tier1 with -XX:+UseShenandoahGC on Linux x86_32 Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Minor cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2185/files - new: https://git.openjdk.java.net/jdk/pull/2185/files/4fd486b5..62170608 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2185&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2185&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2185.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2185/head:pull/2185 PR: https://git.openjdk.java.net/jdk/pull/2185 From iveresov at openjdk.java.net Sun Jan 24 03:53:00 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Sun, 24 Jan 2021 03:53:00 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v5] In-Reply-To: References: Message-ID: > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. > > Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: Address Vladimir's review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1985/files - new: https://git.openjdk.java.net/jdk/pull/1985/files/82dffbe9..74ebbcb5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=03-04 Stats: 78 lines in 20 files changed: 21 ins; 26 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/1985.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1985/head:pull/1985 PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Sun Jan 24 03:56:48 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Sun, 24 Jan 2021 03:56:48 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 17:32:09 GMT, Igor Veresov wrote: >> src/hotspot/share/compiler/compileBroker.cpp line 972: >> >>> 970: >>> 971: // Initialize the compilation queue >>> 972: if (_c2_count > 0) { >> >> Is ZERO treated as `is_interpreter_only()` ? How this change works with ZERO? > > I forgot why I removed that. Let me put it back and run it through testing again. So the reason for that was an awkward possibility of ending up with 0 compilers. That was because during the argument check in ```CompilerConfig::check_args_consistency()``` We checked for ```Arguments::is_interpreter_only()``` instead of ```CompilerConfig::is_interpreter_only()```. The former doesn't check if ```TieredStopAtLevel=0``` is present. Anyways, I fixed the check and reverted this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From rkennke at openjdk.java.net Mon Jan 25 12:50:47 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 25 Jan 2021 12:50:47 GMT Subject: RFR: 8256298: Shenandoah: Enable concurrent stack processing [v2] In-Reply-To: References: Message-ID: On Sun, 24 Jan 2021 01:46:56 GMT, Zhengyu Gu wrote: >> Please review this patch that enables concurrent stack processing for Shenandoah GC. >> >> After this patch, all root processing is done concurrently for concurrent GC. >> >> Test: >> - [x] hotspot_gc_shenandoah Linux x86_64 and x86_32 >> - [x] Nightly >> - [x] tier1 with -XX:+UseShenandoahGC on Linux x86_32 > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Minor cleanup Wow that looks very nice and clean! I only have a few minor comments. src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 512: > 510: // > 511: public: > 512: bool uses_stack_watermark_barrier() const { return true; } This overrides a CollectedHeap method. I wonder if we should start adding 'override' keywords to overridden methods. However, this requires >=C++11, and might disturb backporting. Not sure about it. src/hotspot/share/gc/shenandoah/shenandoahStackWatermark.cpp line 2: > 1: /* > 2: * Copyright (c) 2020, Red Hat, Inc. All rights reserved. This is structurally similar to zStackWatermark.cpp, and perhaps 'inspired' by it. Consider adding Oracle copyright there in addition to the Red Hat copyright. We did the same in e.g. shenandoahReferenceProcessor.hpp/cpp. Also, bump the copyright year to 2021 maybe? src/hotspot/share/gc/shenandoah/shenandoahStackWatermark.hpp line 2: > 1: /* > 2: * Copyright (c) 2020, Red Hat, Inc. All rights reserved. Same comment as in shenandoahStackWatermark.cpp above. ------------- Changes requested by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2185 From zgu at openjdk.java.net Mon Jan 25 13:33:06 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 25 Jan 2021 13:33:06 GMT Subject: RFR: 8256298: Shenandoah: Enable concurrent stack processing [v3] In-Reply-To: References: Message-ID: > Please review this patch that enables concurrent stack processing for Shenandoah GC. > > After this patch, all root processing is done concurrently for concurrent GC. > > Test: > - [x] hotspot_gc_shenandoah Linux x86_64 and x86_32 > - [x] Nightly > - [x] tier1 with -XX:+UseShenandoahGC on Linux x86_32 Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Roman's comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2185/files - new: https://git.openjdk.java.net/jdk/pull/2185/files/62170608..61b3dcb8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2185&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2185&range=01-02 Stats: 5 lines in 3 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2185.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2185/head:pull/2185 PR: https://git.openjdk.java.net/jdk/pull/2185 From rkennke at openjdk.java.net Mon Jan 25 14:27:44 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 25 Jan 2021 14:27:44 GMT Subject: RFR: 8256298: Shenandoah: Enable concurrent stack processing [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 13:33:06 GMT, Zhengyu Gu wrote: >> Please review this patch that enables concurrent stack processing for Shenandoah GC. >> >> After this patch, all root processing is done concurrently for concurrent GC. >> >> Test: >> - [x] hotspot_gc_shenandoah Linux x86_64 and x86_32 >> - [x] Nightly >> - [x] tier1 with -XX:+UseShenandoahGC on Linux x86_32 > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Roman's comments Better, thanks! Found a few more very minor complaints (sorry... ;-) ) src/hotspot/share/gc/shenandoah/shenandoahStackWatermark.cpp line 3: > 1: /* > 2: * Copyright (c) 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. Small nit: the original copyright in the corresponding z* files is dated 2020. Please preserve that. Leave the Red Hat copyright at 2021. Sorry. src/hotspot/share/gc/shenandoah/shenandoahStackWatermark.hpp line 45: > 43: BarrierSetNMethod* _bs_nm; > 44: > 45: virtual void do_code_blob(CodeBlob* cb); There is no need to mark this virtual, or is there? I see you put override in the other place in that change, so maybe put it here too? src/hotspot/share/gc/shenandoah/shenandoahStackWatermark.hpp line 68: > 66: OopClosure* closure_from_context(void* context); > 67: virtual uint32_t epoch_id() const; > 68: virtual void start_processing_impl(void* context); Also, similar to the other case, we might avoid virtual here, and use override instead? ------------- Changes requested by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2185 From shade at openjdk.java.net Mon Jan 25 14:37:52 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 25 Jan 2021 14:37:52 GMT Subject: RFR: 8260106: Shenandoah: simplify maybe_update_with_forwarded and related code [v5] In-Reply-To: References: Message-ID: > We have a block in `ShenandoahHeap::maybe_update_with_forwarded` that is irrelevant after JDK-8231086. Additionally, "resolve and update" paths are really only used by STW GCs, and thus do not require atomic updates. This leads to considerable simplifications in the code, and improves performance on the common paths (especially in fastdebug builds that drop many irrelevant asserts). > > Additional testing: > - [x] `hotspot_gc_shenandoah` > - [x] `tier1` with Shenandoah > - [x] `tier2` with Shenandoah Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Renames - Eliminate UpdateRefsMode altogether - Simplify update_with_forwarded - Comment updates - Merge branch 'master' into JDK-8260106-shenandoah-simplify-updates - Simplify ShenandoahUpdateHeapRefsTask - Fix up generic update references too, introduce CONC_UPDATE - Simplify further after RESOLVE removal - Merge branch 'master' into JDK-8260106-shenandoah-simplify-updates - Rename maybe to atomic - ... and 2 more: https://git.openjdk.java.net/jdk/compare/ca20c63c...f2c1ecdb ------------- Changes: https://git.openjdk.java.net/jdk/pull/2166/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2166&range=04 Stats: 283 lines in 15 files changed: 86 ins; 116 del; 81 mod Patch: https://git.openjdk.java.net/jdk/pull/2166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2166/head:pull/2166 PR: https://git.openjdk.java.net/jdk/pull/2166 From rkennke at openjdk.java.net Mon Jan 25 15:14:45 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 25 Jan 2021 15:14:45 GMT Subject: RFR: 8260106: Shenandoah: simplify maybe_update_with_forwarded and related code [v5] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 14:37:52 GMT, Aleksey Shipilev wrote: >> We have a block in `ShenandoahHeap::maybe_update_with_forwarded` that is irrelevant after JDK-8231086. Additionally, "resolve and update" paths are really only used by STW GCs, and thus do not require atomic updates. This leads to considerable simplifications in the code, and improves performance on the common paths (especially in fastdebug builds that drop many irrelevant asserts). >> >> Additional testing: >> - [x] `hotspot_gc_shenandoah` >> - [x] `tier1` with Shenandoah >> - [x] `tier2` with Shenandoah > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Renames > - Eliminate UpdateRefsMode altogether > - Simplify update_with_forwarded > - Comment updates > - Merge branch 'master' into JDK-8260106-shenandoah-simplify-updates > - Simplify ShenandoahUpdateHeapRefsTask > - Fix up generic update references too, introduce CONC_UPDATE > - Simplify further after RESOLVE removal > - Merge branch 'master' into JDK-8260106-shenandoah-simplify-updates > - Rename maybe to atomic > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/ca20c63c...f2c1ecdb This is indeed much better! I only have a very minor comment, src/hotspot/share/gc/shenandoah/shenandoahOopClosures.hpp line 192: > 190: class ShenandoahUpdateRefsSuperClosure : public BasicOopIterateClosure { > 191: protected: > 192: ShenandoahHeap* _heap; While moving it around, maybe make it Shenandoah* const too? ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2166 From zgu at openjdk.java.net Mon Jan 25 15:18:02 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 25 Jan 2021 15:18:02 GMT Subject: RFR: 8256298: Shenandoah: Enable concurrent stack processing [v4] In-Reply-To: References: Message-ID: > Please review this patch that enables concurrent stack processing for Shenandoah GC. > > After this patch, all root processing is done concurrently for concurrent GC. > > Test: > - [x] hotspot_gc_shenandoah Linux x86_64 and x86_32 > - [x] Nightly > - [x] tier1 with -XX:+UseShenandoahGC on Linux x86_32 Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: More of Roman's comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2185/files - new: https://git.openjdk.java.net/jdk/pull/2185/files/61b3dcb8..77582b33 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2185&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2185&range=02-03 Stats: 8 lines in 2 files changed: 0 ins; 2 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2185.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2185/head:pull/2185 PR: https://git.openjdk.java.net/jdk/pull/2185 From rkennke at openjdk.java.net Mon Jan 25 15:20:43 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 25 Jan 2021 15:20:43 GMT Subject: RFR: 8256298: Shenandoah: Enable concurrent stack processing [v4] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 15:18:02 GMT, Zhengyu Gu wrote: >> Please review this patch that enables concurrent stack processing for Shenandoah GC. >> >> After this patch, all root processing is done concurrently for concurrent GC. >> >> Test: >> - [x] hotspot_gc_shenandoah Linux x86_64 and x86_32 >> - [x] Nightly >> - [x] tier1 with -XX:+UseShenandoahGC on Linux x86_32 > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > More of Roman's comments Looks good to me! Thank you! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2185 From shade at openjdk.java.net Mon Jan 25 15:58:00 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 25 Jan 2021 15:58:00 GMT Subject: RFR: 8260106: Shenandoah: refactor reference updating closures and related code [v6] In-Reply-To: References: Message-ID: > We have a block in `ShenandoahHeap::maybe_update_with_forwarded` that is irrelevant after JDK-8231086. Additionally, "resolve and update" paths are really only used by STW GCs, and thus do not require atomic updates. This leads to considerable simplifications in the code, and improves performance on the common paths (especially in fastdebug builds that drop many irrelevant asserts). > > Additional testing: > - [x] `hotspot_gc_shenandoah` > - [x] `tier1` with Shenandoah > - [x] `tier2` with Shenandoah Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Add const ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2166/files - new: https://git.openjdk.java.net/jdk/pull/2166/files/f2c1ecdb..4f30251d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2166&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2166&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2166/head:pull/2166 PR: https://git.openjdk.java.net/jdk/pull/2166 From shade at openjdk.java.net Mon Jan 25 15:58:02 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 25 Jan 2021 15:58:02 GMT Subject: RFR: 8260106: Shenandoah: refactor reference updating closures and related code [v5] In-Reply-To: References: Message-ID: <1SnRdJcfSYia2BFuiKzmIrRA8UH1RvjbU8cW-0nmtl0=.ee85977a-1a16-49f4-8335-f29c8f8765fe@github.com> On Mon, 25 Jan 2021 15:10:47 GMT, Roman Kennke wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Renames >> - Eliminate UpdateRefsMode altogether >> - Simplify update_with_forwarded >> - Comment updates >> - Merge branch 'master' into JDK-8260106-shenandoah-simplify-updates >> - Simplify ShenandoahUpdateHeapRefsTask >> - Fix up generic update references too, introduce CONC_UPDATE >> - Simplify further after RESOLVE removal >> - Merge branch 'master' into JDK-8260106-shenandoah-simplify-updates >> - Rename maybe to atomic >> - ... and 2 more: https://git.openjdk.java.net/jdk/compare/ca20c63c...f2c1ecdb > > src/hotspot/share/gc/shenandoah/shenandoahOopClosures.hpp line 192: > >> 190: class ShenandoahUpdateRefsSuperClosure : public BasicOopIterateClosure { >> 191: protected: >> 192: ShenandoahHeap* _heap; > > While moving it around, maybe make it Shenandoah* const too? Right! Did in new changeset. ------------- PR: https://git.openjdk.java.net/jdk/pull/2166 From shade at openjdk.java.net Mon Jan 25 16:09:45 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 25 Jan 2021 16:09:45 GMT Subject: RFR: 8256298: Shenandoah: Enable concurrent stack processing [v4] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 15:18:02 GMT, Zhengyu Gu wrote: >> Please review this patch that enables concurrent stack processing for Shenandoah GC. >> >> After this patch, all root processing is done concurrently for concurrent GC. >> >> Test: >> - [x] hotspot_gc_shenandoah Linux x86_64 and x86_32 >> - [x] Nightly >> - [x] tier1 with -XX:+UseShenandoahGC on Linux x86_32 > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > More of Roman's comments Cursory review. src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp line 79: > 77: void ShenandoahKeepAliveClosure::do_oop(narrowOop* p) { > 78: do_oop_work(p); > 79: } These can move to declarations, right? See how the rest of `shenandoahOopClosures.hpp` does it. src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 512: > 510: // > 511: public: > 512: bool uses_stack_watermark_barrier() const override { return true; } I wonder that this single use of `override` caused CLang to complain about the rest of the file: https://github.com/zhengyu123/jdk/runs/1762873416 src/hotspot/share/gc/shenandoah/shenandoahStackWatermark.cpp line 59: > 57: void ShenandoahStackWatermark::change_epoch_id() { > 58: shenandoah_assert_safepoint(); > 59: _epoch_id ++; Excess space before `++`. ------------- PR: https://git.openjdk.java.net/jdk/pull/2185 From gnu.andrew at redhat.com Mon Jan 25 17:07:10 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 25 Jan 2021 17:07:10 +0000 Subject: [aarch64-port-dev ] [RFR] [8u] 8u282-b08 Upstream Sync In-Reply-To: <16d3bc59-4a2f-e366-5510-dab854849145@redhat.com> References: <20210120032842.GA1179631@rincewind> <16d3bc59-4a2f-e366-5510-dab854849145@redhat.com> Message-ID: <20210125170710.GA1819091@rincewind> On 10:59 Wed 20 Jan , Aleksey Shipilev wrote: > On 1/20/21 4:28 AM, Andrew Hughes wrote: > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/corba/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/jaxp/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/jaxws/merge.changeset > > Look trivially good. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/jdk/merge.changeset > > Looks good. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/hotspot/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/langtools/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/nashorn/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u282-b08/root/merge.changeset > > Look trivially good. > > > Ok to push? > > Yes. > > -- > Thanks, > -Aleksey > Thanks. Pushed. -- Andrew :) 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 kvn at openjdk.java.net Mon Jan 25 18:00:52 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 25 Jan 2021 18:00:52 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v5] In-Reply-To: References: Message-ID: On Sun, 24 Jan 2021 03:53:00 GMT, Igor Veresov wrote: >> This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> >> I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. >> >> Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Address Vladimir's review comments Looks better now. I would like to see result of performance testing before approving. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Mon Jan 25 18:15:49 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Mon, 25 Jan 2021 18:15:49 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v5] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 17:57:29 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Address Vladimir's review comments > > Looks better now. I would like to see result of performance testing before approving. I asked Eric to run the benchmarks. The results should be ready on Wednesday. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From zgu at openjdk.java.net Mon Jan 25 18:20:56 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 25 Jan 2021 18:20:56 GMT Subject: RFR: 8256298: Shenandoah: Enable concurrent stack processing [v5] In-Reply-To: References: Message-ID: > Please review this patch that enables concurrent stack processing for Shenandoah GC. > > After this patch, all root processing is done concurrently for concurrent GC. > > Test: > - [x] hotspot_gc_shenandoah Linux x86_64 and x86_32 > - [x] Nightly > - [x] tier1 with -XX:+UseShenandoahGC on Linux x86_32 Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Aleksey's comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2185/files - new: https://git.openjdk.java.net/jdk/pull/2185/files/77582b33..3cab64e8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2185&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2185&range=03-04 Stats: 6 lines in 2 files changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2185.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2185/head:pull/2185 PR: https://git.openjdk.java.net/jdk/pull/2185 From zgu at openjdk.java.net Mon Jan 25 18:27:02 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 25 Jan 2021 18:27:02 GMT Subject: RFR: 8256298: Shenandoah: Enable concurrent stack processing [v6] In-Reply-To: References: Message-ID: > Please review this patch that enables concurrent stack processing for Shenandoah GC. > > After this patch, all root processing is done concurrently for concurrent GC. > > Test: > - [x] hotspot_gc_shenandoah Linux x86_64 and x86_32 > - [x] Nightly > - [x] tier1 with -XX:+UseShenandoahGC on Linux x86_32 Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Reverted override ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2185/files - new: https://git.openjdk.java.net/jdk/pull/2185/files/3cab64e8..6ade41ad Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2185&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2185&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2185.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2185/head:pull/2185 PR: https://git.openjdk.java.net/jdk/pull/2185 From zgu at openjdk.java.net Mon Jan 25 18:27:04 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 25 Jan 2021 18:27:04 GMT Subject: RFR: 8256298: Shenandoah: Enable concurrent stack processing [v4] In-Reply-To: References: Message-ID: <7rVr5fwRs-uKztIZhLlFN7fRGkXPNGKpKnN5WL90Xss=.edb1484f-ad5b-436c-a1d5-e4ff7b23a006@github.com> On Mon, 25 Jan 2021 16:05:44 GMT, Aleksey Shipilev wrote: >> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: >> >> More of Roman's comments > > src/hotspot/share/gc/shenandoah/shenandoahStackWatermark.cpp line 59: > >> 57: void ShenandoahStackWatermark::change_epoch_id() { >> 58: shenandoah_assert_safepoint(); >> 59: _epoch_id ++; > > Excess space before `++`. Done ------------- PR: https://git.openjdk.java.net/jdk/pull/2185 From rkennke at openjdk.java.net Mon Jan 25 20:50:55 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 25 Jan 2021 20:50:55 GMT Subject: RFR: 8260106: Shenandoah: refactor reference updating closures and related code [v6] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 15:58:00 GMT, Aleksey Shipilev wrote: >> We have a block in `ShenandoahHeap::maybe_update_with_forwarded` that is irrelevant after JDK-8231086. Additionally, "resolve and update" paths are really only used by STW GCs, and thus do not require atomic updates. This leads to considerable simplifications in the code, and improves performance on the common paths (especially in fastdebug builds that drop many irrelevant asserts). >> >> Additional testing: >> - [x] `hotspot_gc_shenandoah` >> - [x] `tier1` with Shenandoah >> - [x] `tier2` with Shenandoah > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Add const Looks good! Thanks! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2166 From shade at openjdk.java.net Tue Jan 26 12:01:48 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 26 Jan 2021 12:01:48 GMT Subject: RFR: 8260408: Shenandoah: adjust inline hints after JDK-8255019 Message-ID: <6Jelo9PB6s60HIt-Xsb27tRVJi9G627AAfIzPcSUBzk=.65599cbe-6507-4b5b-848e-404e19889853@github.com> I was following up on performance testing results for some ongoing work, and realized that there are `ShenandoahMarkContext::mark_strong` calls from `mark_work_loop`. Those callees were supposed to be inlined. I believe it is a simple omission after JDK-8255019 moved `mark_work_loop` code to `shenandoahMark.cpp`. On a typical workload: # Before [44.500s][info][gc,stats] Concurrent Marking = 0.395 s (a = 11278 us) (n = 35) (lvls, us = 6426, 9473, 11133, 12891, 16476) # After [44.405s][info][gc,stats] Concurrent Marking = 0.337 s (a = 9636 us) (n = 35) (lvls, us = 3770, 7383, 9785, 11328, 16776) Additional testing: - [x] Eyeballing GC hot paths - [x] Ad-hoc performance tests ------------- Commit messages: - 8260408: Shenandoah: adjust inline hints after JDK-8255019 Changes: https://git.openjdk.java.net/jdk/pull/2235/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2235&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260408 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2235.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2235/head:pull/2235 PR: https://git.openjdk.java.net/jdk/pull/2235 From rkennke at openjdk.java.net Tue Jan 26 12:05:41 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 26 Jan 2021 12:05:41 GMT Subject: RFR: 8260408: Shenandoah: adjust inline hints after JDK-8255019 In-Reply-To: <6Jelo9PB6s60HIt-Xsb27tRVJi9G627AAfIzPcSUBzk=.65599cbe-6507-4b5b-848e-404e19889853@github.com> References: <6Jelo9PB6s60HIt-Xsb27tRVJi9G627AAfIzPcSUBzk=.65599cbe-6507-4b5b-848e-404e19889853@github.com> Message-ID: On Tue, 26 Jan 2021 11:41:52 GMT, Aleksey Shipilev wrote: > I was following up on performance testing results for some ongoing work, and realized that there are `ShenandoahMarkContext::mark_strong` calls from `mark_work_loop`. Those callees were supposed to be inlined. I believe it is a simple omission after JDK-8255019 moved `mark_work_loop` code to `shenandoahMark.cpp`. > > On a typical workload: > > # Before > [44.500s][info][gc,stats] Concurrent Marking = 0.395 s (a = 11278 us) > (n = 35) (lvls, us = 6426, 9473, 11133, 12891, 16476) > > # After > [44.405s][info][gc,stats] Concurrent Marking = 0.337 s (a = 9636 us) > (n = 35) (lvls, us = 3770, 7383, 9785, 11328, 16776) > > Additional testing: > - [x] Eyeballing GC hot paths > - [x] Ad-hoc performance tests Looks good! Thanks! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2235 From shade at openjdk.java.net Tue Jan 26 12:35:47 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 26 Jan 2021 12:35:47 GMT Subject: RFR: 8256298: Shenandoah: Enable concurrent stack processing [v6] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 18:27:02 GMT, Zhengyu Gu wrote: >> Please review this patch that enables concurrent stack processing for Shenandoah GC. >> >> After this patch, all root processing is done concurrently for concurrent GC. >> >> Test: >> - [x] hotspot_gc_shenandoah Linux x86_64 and x86_32 >> - [x] Nightly >> - [x] tier1 with -XX:+UseShenandoahGC on Linux x86_32 > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Reverted override Good job, I have only a few minor comments. src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp line 56: > 54: f(init_manage_tlabs, " Manage TLABs") \ > 55: f(init_update_region_states, " Update Region States") \ > 56: f(scan_roots, " Scan Roots") \ Is `scan_roots` used anywhere still? src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp line 59: > 57: SHENANDOAH_PAR_PHASE_DO(scan_, " S: ", f) \ > 58: \ > 59: f(conc_mark_roots, "Concurrent Mark Roots ") \ This seems like fixing the regression from JDK-8255765, is it not? Should be a separate issue? ------------- Changes requested by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2185 From ihse at openjdk.java.net Tue Jan 26 12:44:40 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 26 Jan 2021 12:44:40 GMT Subject: RFR: 8260408: Shenandoah: adjust inline hints after JDK-8255019 In-Reply-To: <6Jelo9PB6s60HIt-Xsb27tRVJi9G627AAfIzPcSUBzk=.65599cbe-6507-4b5b-848e-404e19889853@github.com> References: <6Jelo9PB6s60HIt-Xsb27tRVJi9G627AAfIzPcSUBzk=.65599cbe-6507-4b5b-848e-404e19889853@github.com> Message-ID: On Tue, 26 Jan 2021 11:41:52 GMT, Aleksey Shipilev wrote: > I was following up on performance testing results for some ongoing work, and realized that there are `ShenandoahMarkContext::mark_strong` calls from `mark_work_loop`. Those callees were supposed to be inlined. I believe it is a simple omission after JDK-8255019 moved `mark_work_loop` code to `shenandoahMark.cpp`. > > On a typical workload: > > # Before > [44.500s][info][gc,stats] Concurrent Marking = 0.395 s (a = 11278 us) > (n = 35) (lvls, us = 6426, 9473, 11133, 12891, 16476) > > # After > [44.405s][info][gc,stats] Concurrent Marking = 0.337 s (a = 9636 us) > (n = 35) (lvls, us = 3770, 7383, 9785, 11328, 16776) > > Additional testing: > - [x] Eyeballing GC hot paths > - [x] Ad-hoc performance tests Looks good from the build PoV. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2235 From shade at redhat.com Tue Jan 26 13:08:25 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 26 Jan 2021 14:08:25 +0100 Subject: [8u] Pick up 8u282 GA to sh/jdk8 Message-ID: I would like to pick up the 8u282 GA to sh/jdk8. Hotspot requires resolving the following conflict: aarch64-port/jdk8u-shenandoah has: Shenandoah: Fix racy update of code roots https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/76dace090781 sh/jdk8 has: [backport] 8229474: Shenandoah: Cleanup CM::update_roots() https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/03dc7e990da2 As far as I can tell, sh/jdk8 removes _update_code_cache, and so aarch64-port/jdk8u-shenandoah change is no longer relevant. Therefore, I accepted the sh/jdk8 side in that conflict. Every other repo is pulled without merges. Testing: hotspot_gc_shenandoah {fastdebug, release} -- Thanks, -Aleksey From shade at openjdk.java.net Tue Jan 26 13:08:42 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 26 Jan 2021 13:08:42 GMT Subject: RFR: 8260408: Shenandoah: adjust inline hints after JDK-8255019 In-Reply-To: References: <6Jelo9PB6s60HIt-Xsb27tRVJi9G627AAfIzPcSUBzk=.65599cbe-6507-4b5b-848e-404e19889853@github.com> Message-ID: On Tue, 26 Jan 2021 12:42:10 GMT, Magnus Ihse Bursie wrote: >> I was following up on performance testing results for some ongoing work, and realized that there are `ShenandoahMarkContext::mark_strong` calls from `mark_work_loop`. Those callees were supposed to be inlined. I believe it is a simple omission after JDK-8255019 moved `mark_work_loop` code to `shenandoahMark.cpp`. >> >> On a typical workload: >> >> # Before >> [44.500s][info][gc,stats] Concurrent Marking = 0.395 s (a = 11278 us) >> (n = 35) (lvls, us = 6426, 9473, 11133, 12891, 16476) >> >> # After >> [44.405s][info][gc,stats] Concurrent Marking = 0.337 s (a = 9636 us) >> (n = 35) (lvls, us = 3770, 7383, 9785, 11328, 16776) >> >> Additional testing: >> - [x] Eyeballing GC hot paths >> - [x] Ad-hoc performance tests > > Looks good from the build PoV. Thanks, GHA reports all builds are green. I would not wait for tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/2235 From shade at openjdk.java.net Tue Jan 26 13:08:43 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 26 Jan 2021 13:08:43 GMT Subject: Integrated: 8260408: Shenandoah: adjust inline hints after JDK-8255019 In-Reply-To: <6Jelo9PB6s60HIt-Xsb27tRVJi9G627AAfIzPcSUBzk=.65599cbe-6507-4b5b-848e-404e19889853@github.com> References: <6Jelo9PB6s60HIt-Xsb27tRVJi9G627AAfIzPcSUBzk=.65599cbe-6507-4b5b-848e-404e19889853@github.com> Message-ID: On Tue, 26 Jan 2021 11:41:52 GMT, Aleksey Shipilev wrote: > I was following up on performance testing results for some ongoing work, and realized that there are `ShenandoahMarkContext::mark_strong` calls from `mark_work_loop`. Those callees were supposed to be inlined. I believe it is a simple omission after JDK-8255019 moved `mark_work_loop` code to `shenandoahMark.cpp`. > > On a typical workload: > > # Before > [44.500s][info][gc,stats] Concurrent Marking = 0.395 s (a = 11278 us) > (n = 35) (lvls, us = 6426, 9473, 11133, 12891, 16476) > > # After > [44.405s][info][gc,stats] Concurrent Marking = 0.337 s (a = 9636 us) > (n = 35) (lvls, us = 3770, 7383, 9785, 11328, 16776) > > Additional testing: > - [x] Eyeballing GC hot paths > - [x] Ad-hoc performance tests This pull request has now been integrated. Changeset: edd27074 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/edd27074 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod 8260408: Shenandoah: adjust inline hints after JDK-8255019 Reviewed-by: rkennke, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/2235 From zgu at openjdk.java.net Tue Jan 26 13:20:40 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 26 Jan 2021 13:20:40 GMT Subject: RFR: 8260106: Shenandoah: refactor reference updating closures and related code [v6] In-Reply-To: References: Message-ID: <9E721gpIaOnuSwQKVGq-Rl01vmSuAGpri9T-XactElU=.8012dc72-d561-4d55-b4e8-9e52300e4c20@github.com> On Mon, 25 Jan 2021 15:58:00 GMT, Aleksey Shipilev wrote: >> We have a block in `ShenandoahHeap::maybe_update_with_forwarded` that is irrelevant after JDK-8231086. Additionally, "resolve and update" paths are really only used by STW GCs, and thus do not require atomic updates. This leads to considerable simplifications in the code, and improves performance on the common paths (especially in fastdebug builds that drop many irrelevant asserts). >> >> Additional testing: >> - [x] `hotspot_gc_shenandoah` >> - [x] `tier1` with Shenandoah >> - [x] `tier2` with Shenandoah > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Add const Still good. ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2166 From shade at openjdk.java.net Tue Jan 26 13:58:49 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 26 Jan 2021 13:58:49 GMT Subject: RFR: 8260106: Shenandoah: refactor reference updating closures and related code [v7] In-Reply-To: References: Message-ID: > We have a block in `ShenandoahHeap::maybe_update_with_forwarded` that is irrelevant after JDK-8231086. Additionally, "resolve and update" paths are really only used by STW GCs, and thus do not require atomic updates. This leads to considerable simplifications in the code, and improves performance on the common paths (especially in fastdebug builds that drop many irrelevant asserts). > > Additional testing: > - [x] `hotspot_gc_shenandoah` > - [x] `tier1` with Shenandoah > - [x] `tier2` with Shenandoah Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Put stars in their old places - Merge branch 'master' into JDK-8260106-shenandoah-simplify-updates - Add const - Renames - Eliminate UpdateRefsMode altogether - Simplify update_with_forwarded - Comment updates - Merge branch 'master' into JDK-8260106-shenandoah-simplify-updates - Simplify ShenandoahUpdateHeapRefsTask - Fix up generic update references too, introduce CONC_UPDATE - ... and 5 more: https://git.openjdk.java.net/jdk/compare/e080ce92...09b2d4aa ------------- Changes: https://git.openjdk.java.net/jdk/pull/2166/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2166&range=06 Stats: 279 lines in 15 files changed: 86 ins; 116 del; 77 mod Patch: https://git.openjdk.java.net/jdk/pull/2166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2166/head:pull/2166 PR: https://git.openjdk.java.net/jdk/pull/2166 From zgu at openjdk.java.net Tue Jan 26 14:08:59 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 26 Jan 2021 14:08:59 GMT Subject: RFR: 8256298: Shenandoah: Enable concurrent stack processing [v7] In-Reply-To: References: Message-ID: > Please review this patch that enables concurrent stack processing for Shenandoah GC. > > After this patch, all root processing is done concurrently for concurrent GC. > > Test: > - [x] hotspot_gc_shenandoah Linux x86_64 and x86_32 > - [x] Nightly > - [x] tier1 with -XX:+UseShenandoahGC on Linux x86_32 Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: More Aleksey's comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2185/files - new: https://git.openjdk.java.net/jdk/pull/2185/files/6ade41ad..ef787198 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2185&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2185&range=05-06 Stats: 27 lines in 3 files changed: 0 ins; 26 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2185.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2185/head:pull/2185 PR: https://git.openjdk.java.net/jdk/pull/2185 From shade at openjdk.java.net Tue Jan 26 15:35:42 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 26 Jan 2021 15:35:42 GMT Subject: RFR: 8256298: Shenandoah: Enable concurrent stack processing [v7] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 14:08:59 GMT, Zhengyu Gu wrote: >> Please review this patch that enables concurrent stack processing for Shenandoah GC. >> >> After this patch, all root processing is done concurrently for concurrent GC. >> >> Test: >> - [x] hotspot_gc_shenandoah Linux x86_64 and x86_32 >> - [x] Nightly >> - [x] tier1 with -XX:+UseShenandoahGC on Linux x86_32 > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > More Aleksey's comments Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2185 From zgu at openjdk.java.net Tue Jan 26 16:49:44 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 26 Jan 2021 16:49:44 GMT Subject: Integrated: 8256298: Shenandoah: Enable concurrent stack processing In-Reply-To: References: Message-ID: <8GosogfhIIocCGgyf-nFB8jdMJK_HhfYcwtts8K0X84=.d242c7fc-f4d8-420e-8533-f72f17b494e4@github.com> On Thu, 21 Jan 2021 17:33:44 GMT, Zhengyu Gu wrote: > Please review this patch that enables concurrent stack processing for Shenandoah GC. > > After this patch, all root processing is done concurrently for concurrent GC. > > Test: > - [x] hotspot_gc_shenandoah Linux x86_64 and x86_32 > - [x] Nightly > - [x] tier1 with -XX:+UseShenandoahGC on Linux x86_32 This pull request has now been integrated. Changeset: fd00ed74 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/fd00ed74 Stats: 672 lines in 19 files changed: 464 ins; 155 del; 53 mod 8256298: Shenandoah: Enable concurrent stack processing Reviewed-by: rkennke, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/2185 From zgu at openjdk.java.net Tue Jan 26 17:00:48 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 26 Jan 2021 17:00:48 GMT Subject: RFR: 8260421: Shenandoah: Fix conc_mark_roots timing name and indentations Message-ID: Please review this trivial patch that renames conc_mark_roots timing name and fixes indentations Test: - [x] hotspot_gc_shenandoah ------------- Commit messages: - JDK-8260421 Changes: https://git.openjdk.java.net/jdk/pull/2241/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2241&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260421 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2241.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2241/head:pull/2241 PR: https://git.openjdk.java.net/jdk/pull/2241 From rkennke at openjdk.java.net Tue Jan 26 17:04:40 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 26 Jan 2021 17:04:40 GMT Subject: RFR: 8260421: Shenandoah: Fix conc_mark_roots timing name and indentations In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 16:55:02 GMT, Zhengyu Gu wrote: > Please review this trivial patch that renames conc_mark_roots timing name and fixes indentations > > Test: > - [x] hotspot_gc_shenandoah Ok! Thanks! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2241 From shade at openjdk.java.net Tue Jan 26 17:39:40 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 26 Jan 2021 17:39:40 GMT Subject: RFR: 8260421: Shenandoah: Fix conc_mark_roots timing name and indentations In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 16:55:02 GMT, Zhengyu Gu wrote: > Please review this trivial patch that renames conc_mark_roots timing name and fixes indentations > > Test: > - [x] hotspot_gc_shenandoah Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2241 From shade at openjdk.java.net Tue Jan 26 18:18:50 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 26 Jan 2021 18:18:50 GMT Subject: RFR: 8260106: Shenandoah: refactor reference updating closures and related code [v8] In-Reply-To: References: Message-ID: > We have a block in `ShenandoahHeap::maybe_update_with_forwarded` that is irrelevant after JDK-8231086. Additionally, "resolve and update" paths are really only used by STW GCs, and thus do not require atomic updates. This leads to considerable simplifications in the code, and improves performance on the common paths (especially in fastdebug builds that drop many irrelevant asserts). > > Additional testing: > - [x] `hotspot_gc_shenandoah` > - [x] `tier1` with Shenandoah > - [x] `tier2` with Shenandoah Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Merge branch 'master' into JDK-8260106-shenandoah-simplify-updates - Put stars in their old places - Merge branch 'master' into JDK-8260106-shenandoah-simplify-updates - Add const - Renames - Eliminate UpdateRefsMode altogether - Simplify update_with_forwarded - Comment updates - Merge branch 'master' into JDK-8260106-shenandoah-simplify-updates - Simplify ShenandoahUpdateHeapRefsTask - ... and 6 more: https://git.openjdk.java.net/jdk/compare/fd00ed74...b2905776 ------------- Changes: https://git.openjdk.java.net/jdk/pull/2166/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2166&range=07 Stats: 279 lines in 15 files changed: 86 ins; 116 del; 77 mod Patch: https://git.openjdk.java.net/jdk/pull/2166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2166/head:pull/2166 PR: https://git.openjdk.java.net/jdk/pull/2166 From rkennke at redhat.com Tue Jan 26 18:46:33 2021 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 26 Jan 2021 19:46:33 +0100 Subject: [8u] Pick up 8u282 GA to sh/jdk8 In-Reply-To: References: Message-ID: Hi Aleksey, > I would like to pick up the 8u282 GA to sh/jdk8. > > Hotspot requires resolving the following conflict: > > aarch64-port/jdk8u-shenandoah has: > ? Shenandoah: Fix racy update of code roots > > https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/76dace090781 > > > sh/jdk8 has: > ? [backport] 8229474: Shenandoah: Cleanup CM::update_roots() > ? https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/03dc7e990da2 > > As far as I can tell, sh/jdk8 removes _update_code_cache, and so > aarch64-port/jdk8u-shenandoah change is no longer relevant. Therefore, I > accepted the sh/jdk8 side in that conflict. Yes, that is correct. The aarch64-port/jdk8u-shenandoah was a conservative fix for the last release, and is superseded by the somewhat-less conservative change in sh/jdk8. > Every other repo is pulled without merges. > > Testing: hotspot_gc_shenandoah {fastdebug, release} Good! Go! Thanks, Roman From shade at redhat.com Tue Jan 26 18:58:10 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 26 Jan 2021 19:58:10 +0100 Subject: [8u] Pick up 8u282 GA to sh/jdk8 In-Reply-To: References: Message-ID: <46124503-e5d1-626a-7dac-8610f21b8763@redhat.com> On 1/26/21 7:46 PM, Roman Kennke wrote: >> I would like to pick up the 8u282 GA to sh/jdk8. >> >> Hotspot requires resolving the following conflict: >> >> aarch64-port/jdk8u-shenandoah has: >> ? Shenandoah: Fix racy update of code roots >> >> https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/76dace090781 >> >> >> sh/jdk8 has: >> ? [backport] 8229474: Shenandoah: Cleanup CM::update_roots() >> ? https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/03dc7e990da2 >> >> As far as I can tell, sh/jdk8 removes _update_code_cache, and so >> aarch64-port/jdk8u-shenandoah change is no longer relevant. Therefore, I >> accepted the sh/jdk8 side in that conflict. > > Yes, that is correct. The aarch64-port/jdk8u-shenandoah was a > conservative fix for the last release, and is superseded by the > somewhat-less conservative change in sh/jdk8. > >> Every other repo is pulled without merges. >> >> Testing: hotspot_gc_shenandoah {fastdebug, release} > > Good! Go! Thank you, pushed. -- -Aleksey From shade at redhat.com Tue Jan 26 18:52:54 2021 From: shade at redhat.com (shade at redhat.com) Date: Tue, 26 Jan 2021 18:52:54 +0000 Subject: hg: shenandoah/jdk8/corba: 38 new changesets Message-ID: <202101261852.10QIqtoe007576@aojmv0008.oracle.com> Changeset: 4da61571ef68 Author: andrew Date: 2020-10-21 02:49 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/4da61571ef68 Added tag jdk8u272-ga for changeset 75460f3d1424 ! .hgtags Changeset: 5528feaa4cb1 Author: andrew Date: 2020-11-04 21:53 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/5528feaa4cb1 Added tag jdk8u275-b00 for changeset 75460f3d1424 ! .hgtags Changeset: beb2c446c6d3 Author: andrew Date: 2020-11-05 02:46 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/beb2c446c6d3 Added tag jdk8u275-b01 for changeset 5528feaa4cb1 ! .hgtags Changeset: 8cdeef8d857d Author: andrew Date: 2020-11-05 05:11 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/8cdeef8d857d Added tag jdk8u275-ga for changeset 5528feaa4cb1 ! .hgtags Changeset: a71ed24956c7 Author: andrew Date: 2020-11-06 03:40 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/a71ed24956c7 Merge jdk8u275-b01 ! .hgtags Changeset: 76cb60e5f446 Author: andrew Date: 2020-11-06 03:45 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/76cb60e5f446 Added tag aarch64-shenandoah-jdk8u275-b01 for changeset a71ed24956c7 ! .hgtags Changeset: ea7d555205fc Author: zgu Date: 2020-09-16 13:41 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/ea7d555205fc 8245400: Upgrade to LittleCMS 2.11 Reviewed-by: serb, jdv ! THIRD_PARTY_README Changeset: 00a48765b96b Author: andrew Date: 2020-09-18 06:41 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/00a48765b96b Merge Changeset: 97d450436564 Author: andrew Date: 2020-09-18 06:43 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/97d450436564 Added tag jdk8u282-b00 for changeset f4d4a3f880da ! .hgtags Changeset: 3267d15de07c Author: andrew Date: 2020-10-30 08:01 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/3267d15de07c Merge ! .hgtags Changeset: 7d35ca4a77bf Author: andrew Date: 2020-11-03 05:58 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/7d35ca4a77bf Added tag jdk8u282-b01 for changeset 3267d15de07c ! .hgtags Changeset: 29073d998344 Author: andrew Date: 2020-12-06 18:43 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/29073d998344 Merge jdk8u282-b01 ! .hgtags ! THIRD_PARTY_README Changeset: 4c794e571757 Author: andrew Date: 2020-12-07 02:28 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/4c794e571757 Added tag aarch64-shenandoah-jdk8u282-b01 for changeset 29073d998344 ! .hgtags Changeset: 4c3c7077a12e Author: andrew Date: 2020-11-16 13:36 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/4c3c7077a12e Merge ! .hgtags Changeset: 5e8cc46c8e08 Author: andrew Date: 2020-11-18 06:55 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/5e8cc46c8e08 Added tag jdk8u282-b02 for changeset 4c3c7077a12e ! .hgtags Changeset: 28764d54218d Author: andrew Date: 2020-12-16 04:19 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/28764d54218d Merge jdk8u282-b02 ! .hgtags Changeset: 0288884a0faa Author: andrew Date: 2020-12-16 04:19 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/0288884a0faa Added tag aarch64-shenandoah-jdk8u282-b02 for changeset 28764d54218d ! .hgtags Changeset: 263f979b9dce Author: andrew Date: 2020-11-24 05:05 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/263f979b9dce Added tag jdk8u282-b03 for changeset 5e8cc46c8e08 ! .hgtags Changeset: eeba46500b72 Author: andrew Date: 2020-12-29 22:39 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/eeba46500b72 Merge jdk8u282-b03 ! .hgtags Changeset: 773c70fee940 Author: andrew Date: 2020-12-29 22:39 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/773c70fee940 Added tag aarch64-shenandoah-jdk8u282-b03 for changeset eeba46500b72 ! .hgtags Changeset: 621241b48e14 Author: joehw Date: 2019-11-22 00:29 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/621241b48e14 8233548: Update CUP to v0.11b Reviewed-by: lancea ! THIRD_PARTY_README Changeset: ea27bde9bc26 Author: ebaron Date: 2020-11-25 12:30 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/ea27bde9bc26 8229868: Update Apache Santuario TPRM version Reviewed-by: phh ! THIRD_PARTY_README Changeset: c666ba7d5c8b Author: andrew Date: 2020-11-27 03:51 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/c666ba7d5c8b Merge Changeset: 48468bfd49dd Author: andrew Date: 2020-12-01 06:34 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/48468bfd49dd Added tag jdk8u282-b04 for changeset c666ba7d5c8b ! .hgtags Changeset: 6cd68997262b Author: andrew Date: 2021-01-06 02:52 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/6cd68997262b Merge jdk8u282-b04 ! .hgtags ! THIRD_PARTY_README Changeset: e7c97fb10ed3 Author: andrew Date: 2021-01-06 02:52 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/e7c97fb10ed3 Added tag aarch64-shenandoah-jdk8u282-b04 for changeset 6cd68997262b ! .hgtags Changeset: ec7169548f2f Author: andrew Date: 2020-12-09 02:45 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/ec7169548f2f Added tag jdk8u282-b05 for changeset 48468bfd49dd ! .hgtags Changeset: e3925e01d0de Author: andrew Date: 2021-01-10 23:25 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/e3925e01d0de Merge jdk8u282-b05 ! .hgtags Changeset: 2deb315f20a3 Author: andrew Date: 2021-01-10 23:26 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/2deb315f20a3 Added tag aarch64-shenandoah-jdk8u282-b05 for changeset e3925e01d0de ! .hgtags Changeset: 37287aaecd27 Author: andrew Date: 2020-12-14 13:44 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/37287aaecd27 Added tag jdk8u282-b06 for changeset ec7169548f2f ! .hgtags Changeset: e9e8745f48ed Author: andrew Date: 2021-01-13 04:30 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/e9e8745f48ed Merge jdk8u282-b06 ! .hgtags Changeset: 4b321fdd2440 Author: andrew Date: 2021-01-13 04:30 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/4b321fdd2440 Added tag aarch64-shenandoah-jdk8u282-b06 for changeset e9e8745f48ed ! .hgtags Changeset: e30b81acf38d Author: andrew Date: 2020-12-29 00:56 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/e30b81acf38d Added tag jdk8u282-b07 for changeset 37287aaecd27 ! .hgtags Changeset: 5eac6a490b0e Author: andrew Date: 2021-01-14 22:49 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/5eac6a490b0e Merge jdk8u282-b07 ! .hgtags Changeset: d9f28600a2ed Author: andrew Date: 2021-01-14 22:50 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/d9f28600a2ed Added tag aarch64-shenandoah-jdk8u282-b07 for changeset 5eac6a490b0e ! .hgtags Changeset: 087af2639ec4 Author: andrew Date: 2021-01-08 04:13 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/087af2639ec4 Added tag jdk8u282-b08 for changeset e30b81acf38d ! .hgtags Changeset: 316bbfe2d120 Author: andrew Date: 2021-01-15 17:21 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/316bbfe2d120 Merge jdk8u282-b08 ! .hgtags Changeset: 8a9c035afe5f Author: andrew Date: 2021-01-15 17:21 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/8a9c035afe5f Added tag aarch64-shenandoah-jdk8u282-b08 for changeset 316bbfe2d120 ! .hgtags From shade at redhat.com Tue Jan 26 18:52:54 2021 From: shade at redhat.com (shade at redhat.com) Date: Tue, 26 Jan 2021 18:52:54 +0000 Subject: hg: shenandoah/jdk8/jaxp: 38 new changesets Message-ID: <202101261852.10QIqsOI007572@aojmv0008.oracle.com> Changeset: 560ea469eecd Author: andrew Date: 2020-10-21 02:49 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/560ea469eecd Added tag jdk8u272-ga for changeset ba503169016f ! .hgtags Changeset: 5ea8152e5165 Author: andrew Date: 2020-11-04 21:53 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/5ea8152e5165 Added tag jdk8u275-b00 for changeset ba503169016f ! .hgtags Changeset: ed3d3f4a4d44 Author: andrew Date: 2020-11-05 02:46 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/ed3d3f4a4d44 Added tag jdk8u275-b01 for changeset 5ea8152e5165 ! .hgtags Changeset: 26159363f4cc Author: andrew Date: 2020-11-05 05:11 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/26159363f4cc Added tag jdk8u275-ga for changeset 5ea8152e5165 ! .hgtags Changeset: d7eaa98bd647 Author: andrew Date: 2020-11-06 03:40 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/d7eaa98bd647 Merge jdk8u275-b01 ! .hgtags Changeset: 6570147668c5 Author: andrew Date: 2020-11-06 03:45 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/6570147668c5 Added tag aarch64-shenandoah-jdk8u275-b01 for changeset d7eaa98bd647 ! .hgtags Changeset: bfd556987dfb Author: zgu Date: 2020-09-16 13:41 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/bfd556987dfb 8245400: Upgrade to LittleCMS 2.11 Reviewed-by: serb, jdv ! THIRD_PARTY_README Changeset: 86c77fa3bbd5 Author: andrew Date: 2020-09-18 06:41 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/86c77fa3bbd5 Merge Changeset: d35045d457c1 Author: andrew Date: 2020-09-18 06:43 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/d35045d457c1 Added tag jdk8u282-b00 for changeset 44cbebcc276c ! .hgtags Changeset: b5aa45b631e7 Author: andrew Date: 2020-10-30 08:01 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/b5aa45b631e7 Merge ! .hgtags Changeset: f190507bf7fc Author: andrew Date: 2020-11-03 05:58 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/f190507bf7fc Added tag jdk8u282-b01 for changeset b5aa45b631e7 ! .hgtags Changeset: 7f3b46cc1e22 Author: andrew Date: 2020-12-06 18:43 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/7f3b46cc1e22 Merge jdk8u282-b01 ! .hgtags ! THIRD_PARTY_README Changeset: 305b280f20e6 Author: andrew Date: 2020-12-07 02:28 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/305b280f20e6 Added tag aarch64-shenandoah-jdk8u282-b01 for changeset 7f3b46cc1e22 ! .hgtags Changeset: 644350e6f773 Author: andrew Date: 2020-11-16 13:36 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/644350e6f773 Merge ! .hgtags Changeset: f856f0cf15c1 Author: andrew Date: 2020-11-18 06:55 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/f856f0cf15c1 Added tag jdk8u282-b02 for changeset 644350e6f773 ! .hgtags Changeset: 8d4a4410932c Author: andrew Date: 2020-12-16 04:19 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/8d4a4410932c Merge jdk8u282-b02 ! .hgtags Changeset: 0ba5d1d239bc Author: andrew Date: 2020-12-16 04:19 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/0ba5d1d239bc Added tag aarch64-shenandoah-jdk8u282-b02 for changeset 8d4a4410932c ! .hgtags Changeset: 79bb1bbadb44 Author: andrew Date: 2020-11-24 05:05 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/79bb1bbadb44 Added tag jdk8u282-b03 for changeset f856f0cf15c1 ! .hgtags Changeset: 067fae8f8e1e Author: andrew Date: 2020-12-29 22:39 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/067fae8f8e1e Merge jdk8u282-b03 ! .hgtags Changeset: 8633fab1e848 Author: andrew Date: 2020-12-29 22:39 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/8633fab1e848 Added tag aarch64-shenandoah-jdk8u282-b03 for changeset 067fae8f8e1e ! .hgtags Changeset: 207b1f5660c7 Author: joehw Date: 2019-11-22 00:29 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/207b1f5660c7 8233548: Update CUP to v0.11b Reviewed-by: lancea ! THIRD_PARTY_README ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/XPathParser.java Changeset: 6b34545c0bc1 Author: ebaron Date: 2020-11-25 14:29 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/6b34545c0bc1 8229868: Update Apache Santuario TPRM version Reviewed-by: phh ! THIRD_PARTY_README Changeset: bbaa1d8d7979 Author: andrew Date: 2020-11-27 03:51 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/bbaa1d8d7979 Merge Changeset: f9651f512384 Author: andrew Date: 2020-12-01 06:34 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/f9651f512384 Added tag jdk8u282-b04 for changeset bbaa1d8d7979 ! .hgtags Changeset: 9f0410d8d3e7 Author: andrew Date: 2021-01-06 02:52 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/9f0410d8d3e7 Merge jdk8u282-b04 ! .hgtags ! THIRD_PARTY_README Changeset: 7f28787146e8 Author: andrew Date: 2021-01-06 02:52 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/7f28787146e8 Added tag aarch64-shenandoah-jdk8u282-b04 for changeset 9f0410d8d3e7 ! .hgtags Changeset: 8ea91dc70369 Author: andrew Date: 2020-12-09 02:45 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/8ea91dc70369 Added tag jdk8u282-b05 for changeset f9651f512384 ! .hgtags Changeset: 561976d0bfb9 Author: andrew Date: 2021-01-10 23:25 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/561976d0bfb9 Merge jdk8u282-b05 ! .hgtags Changeset: 86d6a4c5b754 Author: andrew Date: 2021-01-10 23:26 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/86d6a4c5b754 Added tag aarch64-shenandoah-jdk8u282-b05 for changeset 561976d0bfb9 ! .hgtags Changeset: 2f37a3e87454 Author: andrew Date: 2020-12-14 13:44 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/2f37a3e87454 Added tag jdk8u282-b06 for changeset 8ea91dc70369 ! .hgtags Changeset: 0e5e92f551b7 Author: andrew Date: 2021-01-13 04:30 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/0e5e92f551b7 Merge jdk8u282-b06 ! .hgtags Changeset: 8f781e853ca9 Author: andrew Date: 2021-01-13 04:30 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/8f781e853ca9 Added tag aarch64-shenandoah-jdk8u282-b06 for changeset 0e5e92f551b7 ! .hgtags Changeset: 925d9ec1246e Author: andrew Date: 2020-12-29 00:56 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/925d9ec1246e Added tag jdk8u282-b07 for changeset 2f37a3e87454 ! .hgtags Changeset: 37a706752cbe Author: andrew Date: 2021-01-14 22:49 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/37a706752cbe Merge jdk8u282-b07 ! .hgtags Changeset: 3360f8eac589 Author: andrew Date: 2021-01-14 22:50 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/3360f8eac589 Added tag aarch64-shenandoah-jdk8u282-b07 for changeset 37a706752cbe ! .hgtags Changeset: 64631fdcacca Author: andrew Date: 2021-01-08 04:13 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/64631fdcacca Added tag jdk8u282-b08 for changeset 925d9ec1246e ! .hgtags Changeset: 5624143d56aa Author: andrew Date: 2021-01-15 17:21 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/5624143d56aa Merge jdk8u282-b08 ! .hgtags Changeset: de4b9d814d07 Author: andrew Date: 2021-01-15 17:21 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/de4b9d814d07 Added tag aarch64-shenandoah-jdk8u282-b08 for changeset 5624143d56aa ! .hgtags From shade at redhat.com Tue Jan 26 18:53:00 2021 From: shade at redhat.com (shade at redhat.com) Date: Tue, 26 Jan 2021 18:53:00 +0000 Subject: hg: shenandoah/jdk8/hotspot: 85 new changesets Message-ID: <202101261853.10QIr1BI007588@aojmv0008.oracle.com> Changeset: 73f624a2488d Author: andrew Date: 2020-10-21 02:49 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/73f624a2488d Added tag jdk8u272-ga for changeset 6b836efa38fe ! .hgtags Changeset: bc6816b211db Author: andrew Date: 2020-11-04 21:53 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/bc6816b211db Added tag jdk8u275-b00 for changeset 6b836efa38fe ! .hgtags Changeset: b36c3f635d93 Author: thartmann Date: 2020-08-06 08:10 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b36c3f635d93 8250861: Crash in MinINode::Ideal(PhaseGVN*, bool) Summary: Added missing NULL checks. Reviewed-by: kvn, chagedorn ! src/share/vm/opto/addnode.cpp Changeset: 62cafa6a7ccc Author: andrew Date: 2020-11-05 02:46 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/62cafa6a7ccc Added tag jdk8u275-b01 for changeset b36c3f635d93 ! .hgtags Changeset: b36870ac13f5 Author: andrew Date: 2020-11-05 05:11 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b36870ac13f5 Added tag jdk8u275-ga for changeset b36c3f635d93 ! .hgtags Changeset: bef9421300e3 Author: andrew Date: 2020-11-06 03:40 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/bef9421300e3 Merge jdk8u275-b01 ! .hgtags ! src/share/vm/opto/addnode.cpp Changeset: 54aa3fd1151f Author: andrew Date: 2020-11-06 03:45 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/54aa3fd1151f Added tag aarch64-shenandoah-jdk8u275-b01 for changeset bef9421300e3 ! .hgtags Changeset: 3e0eb70a007e Author: zgu Date: 2019-11-26 09:27 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/3e0eb70a007e 8234270: [REDO] JDK-8204128 NMT might report incorrect numbers for Compiler area Reviewed-by: stuefe, minqi ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/resourceArea.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/services/mallocTracker.hpp ! src/share/vm/services/memTracker.hpp + test/runtime/NMT/HugeArenaTracking.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 6d0e445c7814 Author: kbarrett Date: 2016-09-15 12:10 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/6d0e445c7814 8165808: Add release barriers when allocating objects with concurrent collection Summary: Add release_set_klass, use in slow-path allocators. Reviewed-by: jmasa, dholmes, aph ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp Changeset: e05b04137e36 Author: zgu Date: 2020-09-16 13:32 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/e05b04137e36 8245400: Upgrade to LittleCMS 2.11 Reviewed-by: serb, jdv ! THIRD_PARTY_README Changeset: 134465df86df Author: andrew Date: 2020-09-18 06:41 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/134465df86df Merge Changeset: 2de695626bf5 Author: andrew Date: 2020-09-18 06:43 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/2de695626bf5 Added tag jdk8u282-b00 for changeset 4b0aa85a9565 ! .hgtags Changeset: 8065f7b6bea3 Author: uvangapally Date: 2017-10-05 01:31 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/8065f7b6bea3 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument Summary: Added two new API's to limit the stack trace depth Reviewed-by: mchung, dfuchs, rriggs, egahlin Contributed-by: ujwal.vangapally at oracle.com ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp ! src/share/vm/services/threadService.cpp Changeset: a3ac2e49cb4f Author: jbachorik Date: 2020-09-24 13:19 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/a3ac2e49cb4f 8250928: JFR: Improve hash algorithm for stack traces Reviewed-by: shade ! src/share/vm/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp Changeset: 04b1e9e7509d Author: jbachorik Date: 2020-09-24 13:19 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/04b1e9e7509d 8252754: Hash code calculation of JfrStackTrace is inconsistent Reviewed-by: shade ! src/share/vm/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp Changeset: 49dcf5b44dcb Author: phh Date: 2019-09-25 15:22 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/49dcf5b44dcb 8231209: [REDO] ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread Summary: Add com.sun.management.getCurrentThreadAllocatedBytes, implement getThreadAllocatedBytes(long) independent of getThreadAllocatedBytes(long[]) Reviewed-by: mchung, dholmes, sspitsyn ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp Changeset: 0277358b8fc2 Author: apetushkov Date: 2020-10-01 15:52 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/0277358b8fc2 8252904: VM crashes when JFR is used and JFR event class is transformed Summary: set callers of ClassFileParser.parseClassFile responsible for putting ResourceMark Reviewed-by: adinn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/systemDictionary.cpp Changeset: 5be342825cfd Author: mduigou Date: 2014-02-12 09:37 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/5be342825cfd 8030350: Enable additional compiler warnings for GCC Reviewed-by: dholmes, coleenp, erikj, tbell, ihse ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/gcc.make ! src/os/bsd/vm/os_bsd.cpp Changeset: 6d9380c7c0ba Author: goetz Date: 2014-03-03 11:54 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/6d9380c7c0ba 8036122: Fix warning 'format not a string literal' Reviewed-by: mduigou, kvn ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/gcc.make ! src/os/linux/vm/os_linux.cpp ! src/share/vm/compiler/compilerOracle.cpp Changeset: 007d682bf5d0 Author: stefank Date: 2014-11-12 13:55 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/007d682bf5d0 8062808: Turn on the -Wreturn-type warning Reviewed-by: mgerdin, tschatzl, coleenp, jrose, kbarrett ! make/linux/makefiles/gcc.make ! src/cpu/x86/vm/x86_32.ad ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/metaspaceShared.hpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/perfData.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/services/memTracker.hpp Changeset: 002b9c947f0f Author: goetz Date: 2020-06-10 11:33 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/002b9c947f0f 8244225: stringop-overflow warning on strncpy call from compile_the_world_in Reviewed-by: aph, shade, andrew ! src/share/vm/classfile/classLoader.cpp Changeset: 321a84a5e5b8 Author: mgronlun Date: 2018-12-21 16:56 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/321a84a5e5b8 8215727: Restore JFR thread sampler loop to old / previous behavior Reviewed-by: egahlin, mgronlun Contributed-by: milan.mimica at gmail.com ! src/share/vm/jfr/periodic/sampling/jfrThreadSampler.cpp Changeset: bc185d95c9f5 Author: shade Date: 2020-09-22 08:33 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/bc185d95c9f5 8253284: Zero OrderAccess barrier mappings are incorrect Reviewed-by: dholmes, aph, andrew ! src/os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp ! src/os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp Changeset: 1dde8affa7e6 Author: shade Date: 2018-11-19 11:51 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/1dde8affa7e6 8212070: Introduce diagnostic flag to abort VM on failed JIT compilation Reviewed-by: mikael, thartmann ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/globals.hpp Changeset: 3c4577d95636 Author: shade Date: 2020-10-08 08:10 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/3c4577d95636 8254166: Zero: return-type warning in zeroInterpreter_zero.cpp Reviewed-by: sgehwolf ! src/cpu/zero/vm/cppInterpreter_zero.cpp Changeset: de90eec825b4 Author: mseledtsov Date: 2019-03-26 13:25 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/de90eec825b4 8221342: [TESTBUG] Generate Dockerfile for docker testing Summary: Dockerfile is generated; introduced properties to specify custom base image Reviewed-by: sgehwolf, dholmes, jiefu - test/runtime/containers/docker/Dockerfile-BasicTest - test/runtime/containers/docker/Dockerfile-BasicTest-aarch64 - test/runtime/containers/docker/Dockerfile-BasicTest-ppc64le - test/runtime/containers/docker/Dockerfile-BasicTest-s390x ! test/testlibrary/com/oracle/java/testlibrary/DockerTestUtils.java + test/testlibrary/com/oracle/java/testlibrary/DockerfileConfig.java Changeset: 308ed1ae8a75 Author: andrew Date: 2020-10-26 07:04 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/308ed1ae8a75 8253036: Support building the Zero assembler port on AArch64 Summary: Add recognition of the ELF format on AArch64 to allow Zero builds on the platform. Reviewed-by: shade ! src/os/linux/vm/os_linux.cpp Changeset: a9ac254e093c Author: shade Date: 2020-10-26 07:23 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/a9ac254e093c 8197981: Missing return statement in __sync_val_compare_and_swap_8 8254144: Non-x86 Zero builds fail with return-type warning in os_linux_zero.cpp Reviewed-by: andrew, dholmes, zgu ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp Changeset: b78fc497bdf2 Author: andrew Date: 2020-10-30 08:02 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b78fc497bdf2 Merge ! .hgtags ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/reflection.cpp - test/runtime/ClassFile/BadHelloWorld.jcod - test/runtime/ClassFile/FormatCheckingTest.java Changeset: 879099c6cc10 Author: zgu Date: 2016-08-25 09:23 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/879099c6cc10 8148854: Class names "SomeClass" and "LSomeClass;" treated by JVM as an equivalent Summary: Added default format checking of class names loaded by the app class loader Reviewed-by: andrew ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/runtime/reflection.cpp + test/runtime/ClassFile/BadHelloWorld.jcod + test/runtime/ClassFile/FormatCheckingTest.java Changeset: d8f1fd8de0a9 Author: qpzhang Date: 2020-06-16 23:15 +0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/d8f1fd8de0a9 8248214: Add paddings for TaskQueueSuper to reduce false-sharing cache contention Summary: This is a downport of a part of JDK-8243326 Reviewed-by: goetz, clanger ! src/share/vm/memory/padded.hpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 19ab41f1f588 Author: andrew Date: 2020-10-30 08:13 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/19ab41f1f588 Merge Changeset: 7f7c1e1fbc8a Author: thartmann Date: 2020-08-06 08:10 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/7f7c1e1fbc8a 8250861: Crash in MinINode::Ideal(PhaseGVN*, bool) Summary: Added missing NULL checks. Reviewed-by: kvn, chagedorn ! src/share/vm/opto/addnode.cpp Changeset: 91bed84d3ef3 Author: andrew Date: 2020-11-03 05:58 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/91bed84d3ef3 Added tag jdk8u282-b01 for changeset 7f7c1e1fbc8a ! .hgtags Changeset: 5862a1484930 Author: andrew Date: 2020-12-07 02:25 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/5862a1484930 Merge jdk8u282-b01 ! .hgtags ! THIRD_PARTY_README ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/gcc.make ! src/cpu/x86/vm/x86_32.ad ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/metaspaceShared.hpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp ! src/share/vm/services/threadService.cpp ! src/share/vm/utilities/taskqueue.hpp - test/runtime/containers/docker/Dockerfile-BasicTest - test/runtime/containers/docker/Dockerfile-BasicTest-aarch64 - test/runtime/containers/docker/Dockerfile-BasicTest-ppc64le - test/runtime/containers/docker/Dockerfile-BasicTest-s390x ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 77179c89b46b Author: andrew Date: 2020-12-07 02:28 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/77179c89b46b Added tag aarch64-shenandoah-jdk8u282-b01 for changeset 5862a1484930 ! .hgtags Changeset: 76dace090781 Author: rkennke Date: 2020-12-15 20:18 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/76dace090781 Shenandoah: Fix racy update of code roots Reviewed-by: zgu, andrew ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp Changeset: 96cdb50fe0bf Author: andrew Date: 2020-11-16 13:36 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/96cdb50fe0bf Merge ! .hgtags - test/runtime/containers/docker/Dockerfile-BasicTest - test/runtime/containers/docker/Dockerfile-BasicTest-aarch64 - test/runtime/containers/docker/Dockerfile-BasicTest-ppc64le - test/runtime/containers/docker/Dockerfile-BasicTest-s390x Changeset: 53a1332a8d25 Author: hshi Date: 2020-10-19 19:21 +0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/53a1332a8d25 8253837: JFR 8u fix symbol and cstring hashtable equals implementaion Reviewed-by: adinn ! src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSet.cpp ! src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSetUtils.cpp ! src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSetUtils.hpp Changeset: 3b255f489efa Author: phh Date: 2020-10-27 15:13 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/3b255f489efa 8255269: Unsigned overflow in g1Policy.cpp Reviewed-by: yan Contributed-by: William Kemper ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 57a0726f3c0a Author: andrew Date: 2020-11-18 06:47 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/57a0726f3c0a Merge Changeset: 312e9cb580c5 Author: andrew Date: 2020-11-18 06:50 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/312e9cb580c5 Merge Changeset: 83661fdee9f0 Author: andrew Date: 2020-11-18 06:55 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/83661fdee9f0 Added tag jdk8u282-b02 for changeset 312e9cb580c5 ! .hgtags Changeset: 9b1011314b81 Author: andrew Date: 2020-12-16 04:19 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/9b1011314b81 Merge jdk8u282-b02 ! .hgtags ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 4461fb07f3e5 Author: andrew Date: 2020-12-16 04:19 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/4461fb07f3e5 Added tag aarch64-shenandoah-jdk8u282-b02 for changeset 9b1011314b81 ! .hgtags Changeset: f9f19940bf72 Author: andrew Date: 2020-11-24 05:05 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/f9f19940bf72 Added tag jdk8u282-b03 for changeset 83661fdee9f0 ! .hgtags Changeset: 35207ce910d8 Author: andrew Date: 2020-12-29 22:39 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/35207ce910d8 Merge jdk8u282-b03 ! .hgtags Changeset: 4900e015a419 Author: andrew Date: 2020-12-29 22:39 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/4900e015a419 Added tag aarch64-shenandoah-jdk8u282-b03 for changeset 35207ce910d8 ! .hgtags Changeset: 3b709de4d644 Author: shade Date: 2021-01-05 17:08 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/3b709de4d644 Fix AArch64 build failure after JDK-8062808 backport Reviewed-by: aph, andrew ! src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp Changeset: 22ec1c43273b Author: bobv Date: 2019-10-31 19:32 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/22ec1c43273b 8227006: [linux] Runtime.availableProcessors execution time increased by factor of 100 Reviewed-by: andrew, sgehwolf Contributed-by: jdowland at redhat.com ! src/os/linux/vm/osContainer_linux.cpp ! src/os/linux/vm/osContainer_linux.hpp Changeset: e5c6b19dd8fc Author: shade Date: 2016-06-22 13:29 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/e5c6b19dd8fc 8156803: Turn StressLCM/StressGCM flags to diagnostic Reviewed-by: kvn, ctornqvi ! src/share/vm/opto/c2_globals.hpp Changeset: b90e951950c7 Author: ppunegov Date: 2016-07-13 19:08 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b90e951950c7 8160761: [TESTBUG] Several compiler tests fail with product bits Summary: Add UnlockDiagnosticVMOptions to tests Reviewed-by: goetz ! test/compiler/membars/DekkerTest.java Changeset: 9cf4c59c7395 Author: egahlin Date: 2017-12-01 17:03 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/9cf4c59c7395 8179083: Uninitialized notifier in Java Monitor Wait tracing event Reviewed-by: mgronlun, phh ! src/share/vm/runtime/objectMonitor.cpp Changeset: b4a58a1cd60f Author: kbarrett Date: 2016-09-23 18:23 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b4a58a1cd60f 8166583: Add oopDesc::klass_or_null_acquire() Summary: Added new function. Reviewed-by: dholmes, tschatzl, adinn ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp Changeset: be47c996965c Author: kbarrett Date: 2016-10-21 22:26 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/be47c996965c 8166862: CMS needs klass_or_null_acquire Summary: Change CMS non-assert uses of klass_or_null to klass_or_null_acquire. Reviewed-by: tschatzl, mgerdin, adinn ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: 1825208d432f Author: kbarrett Date: 2016-09-26 14:38 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/1825208d432f 8166663: Simplify oops_on_card_seq_iterate_careful Summary: Remove unnecessary parameter, change return value. Reviewed-by: tschatzl, mgerdin, phh ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 1a2714e736d0 Author: mseledtsov Date: 2019-04-04 12:29 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/1a2714e736d0 8221710: [TESTBUG] more configurable parameters for docker testing Summary: Introduced docker test config properties Reviewed-by: lmesnik, iignatyev, egahlin, phh ! test/runtime/containers/docker/DockerBasicTest.java ! test/testlibrary/com/oracle/java/testlibrary/DockerTestUtils.java Changeset: 739dd6193ede Author: joehw Date: 2019-11-22 00:29 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/739dd6193ede 8233548: Update CUP to v0.11b Reviewed-by: lancea ! THIRD_PARTY_README Changeset: 5f51c6044a7c Author: hshi Date: 2020-11-12 20:01 +0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/5f51c6044a7c 8255717: Fix JFR crash in WriteObjectSampleStacktrace due to object not initialized Reviewed-by: phh ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp Changeset: 3fcf88579cd6 Author: ebaron Date: 2020-11-25 12:30 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/3fcf88579cd6 8229868: Update Apache Santuario TPRM version Reviewed-by: phh ! THIRD_PARTY_README Changeset: d29cb0e3dfd9 Author: andrew Date: 2020-11-27 03:51 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/d29cb0e3dfd9 Merge Changeset: 3a93682b0b44 Author: shade Date: 2020-11-24 12:26 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/3a93682b0b44 8256618: Zero: Linux x86_32 build still fails Reviewed-by: aph, dholmes, stuefe ! src/os/linux/vm/os_linux.cpp Changeset: 516928837b4a Author: iignatyev Date: 2014-05-28 14:42 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/516928837b4a 8043899: compiler/5091921/Test7005594.java fails if specified -Xmx is less than 1600m Reviewed-by: kvn, twisti, vlivanov ! test/compiler/5091921/Test7005594.sh Changeset: 22f755afb22b Author: bobv Date: 2019-03-19 12:00 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/22f755afb22b 8219562: Line of code in osContainer_linux.cpp L102 appears unreachable Reviewed-by: rriggs, sgehwolf ! src/os/linux/vm/osContainer_linux.cpp Changeset: 812256bab2b6 Author: bobv Date: 2019-03-19 12:29 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/812256bab2b6 8217766: Container Support doesn't work for some Join Controllers combinations Reviewed-by: rriggs, sgehwolf ! src/os/linux/vm/osContainer_linux.cpp Changeset: 46bd8a39ef9c Author: snazarki Date: 2020-08-10 11:25 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/46bd8a39ef9c 8250636: iso8601_time returns incorrect offset part on MacOS Reviewed-by: phh, andrew ! src/share/vm/runtime/os.cpp Changeset: 1df9d5db32db Author: snazarki Date: 2020-08-11 13:03 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/1df9d5db32db 8251365: Build failure on AIX after 8250636 Reviewed-by: phh, andrew ! src/share/vm/runtime/os.cpp Changeset: 80747d91749a Author: lzang Date: 2020-12-01 05:21 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/80747d91749a 8256671: Incorrect assignment operator used in guarantee() in genCollectedHeap Reviewed-by: aph, phh, andrew ! src/share/vm/memory/genCollectedHeap.cpp Changeset: d7c102fe9c47 Author: evergizova Date: 2019-03-25 15:37 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/d7c102fe9c47 8217362: Emergency dump does not work when disk=false is set Reviewed-by: phh, andrew ! src/share/vm/jfr/recorder/repository/jfrChunkWriter.cpp ! src/share/vm/jfr/recorder/repository/jfrEmergencyDump.cpp ! src/share/vm/jfr/recorder/repository/jfrEmergencyDump.hpp ! src/share/vm/jfr/recorder/repository/jfrRepository.cpp Changeset: d84cbe66ce9f Author: andrew Date: 2020-12-01 06:35 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/d84cbe66ce9f Added tag jdk8u282-b04 for changeset d7c102fe9c47 ! .hgtags Changeset: b40010ce72b7 Author: andrew Date: 2021-01-06 02:52 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b40010ce72b7 Merge jdk8u282-b04 ! .hgtags ! THIRD_PARTY_README ! src/os/linux/vm/os_linux.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/runtime/objectMonitor.cpp Changeset: ac4e48445c86 Author: andrew Date: 2021-01-06 02:52 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/ac4e48445c86 Added tag aarch64-shenandoah-jdk8u282-b04 for changeset b40010ce72b7 ! .hgtags Changeset: a29ba3f778d7 Author: andrew Date: 2020-12-09 02:45 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/a29ba3f778d7 Added tag jdk8u282-b05 for changeset d84cbe66ce9f ! .hgtags Changeset: 8ca18cea1c6f Author: andrew Date: 2021-01-10 23:25 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/8ca18cea1c6f Merge jdk8u282-b05 ! .hgtags Changeset: a71e35c563e1 Author: andrew Date: 2021-01-10 23:26 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/a71e35c563e1 Added tag aarch64-shenandoah-jdk8u282-b05 for changeset 8ca18cea1c6f ! .hgtags Changeset: 3d42d5d7117d Author: andrew Date: 2020-12-14 13:45 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/3d42d5d7117d Added tag jdk8u282-b06 for changeset a29ba3f778d7 ! .hgtags Changeset: a59104c6e41d Author: andrew Date: 2021-01-13 04:30 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/a59104c6e41d Merge jdk8u282-b06 ! .hgtags Changeset: b6dad01a4b60 Author: andrew Date: 2021-01-13 04:30 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b6dad01a4b60 Added tag aarch64-shenandoah-jdk8u282-b06 for changeset a59104c6e41d ! .hgtags Changeset: fcfacb8f9da0 Author: andrew Date: 2020-12-29 00:56 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/fcfacb8f9da0 Added tag jdk8u282-b07 for changeset 3d42d5d7117d ! .hgtags Changeset: 29fa361ac0b3 Author: andrew Date: 2021-01-14 22:49 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/29fa361ac0b3 Merge jdk8u282-b07 ! .hgtags Changeset: fd7c6ac9a6c7 Author: andrew Date: 2021-01-14 22:50 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/fd7c6ac9a6c7 Added tag aarch64-shenandoah-jdk8u282-b07 for changeset 29fa361ac0b3 ! .hgtags Changeset: fb6fa562781e Author: andrew Date: 2021-01-08 04:13 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/fb6fa562781e Added tag jdk8u282-b08 for changeset fcfacb8f9da0 ! .hgtags Changeset: 6c6414cb341e Author: andrew Date: 2021-01-15 17:21 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/6c6414cb341e Merge jdk8u282-b08 ! .hgtags Changeset: c62919919a6f Author: andrew Date: 2021-01-15 17:21 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/c62919919a6f Added tag aarch64-shenandoah-jdk8u282-b08 for changeset 6c6414cb341e ! .hgtags Changeset: 6fa834d4a980 Author: shade Date: 2021-01-26 14:04 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/6fa834d4a980 Merge ! src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp From shade at redhat.com Tue Jan 26 18:53:17 2021 From: shade at redhat.com (shade at redhat.com) Date: Tue, 26 Jan 2021 18:53:17 +0000 Subject: hg: shenandoah/jdk8/jdk: 148 new changesets Message-ID: <202101261853.10QIrMdM007740@aojmv0008.oracle.com> Changeset: eb7f437285a1 Author: andrew Date: 2020-10-21 02:49 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/eb7f437285a1 Added tag jdk8u272-ga for changeset badfd40f15ac ! .hgtags Changeset: ea8bd96492c6 Author: andrew Date: 2020-11-04 21:53 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/ea8bd96492c6 Added tag jdk8u275-b00 for changeset badfd40f15ac ! .hgtags Changeset: 10149d2837c2 Author: robm Date: 2019-01-10 07:54 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/10149d2837c2 8214440: ldap over a TLS connection negotiate failed with "javax.net.ssl.SSLPeerUnverifiedException: hostname of the server '' does not match the hostname in the server's certificate" Reviewed-by: vtewari, xuelei ! src/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java Changeset: e5da2855d413 Author: xuelei Date: 2019-11-06 09:45 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/e5da2855d413 8223940: Private key not supported by chosen signature algorithm Reviewed-by: valeriep ! src/share/classes/sun/security/ssl/CertificateVerify.java ! src/share/classes/sun/security/ssl/DHServerKeyExchange.java ! src/share/classes/sun/security/ssl/ECDHServerKeyExchange.java ! src/share/classes/sun/security/ssl/SignatureScheme.java Changeset: efb922cd7ac4 Author: valeriep Date: 2020-10-30 07:09 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/efb922cd7ac4 8236512: PKCS11 Connection closed after Cipher.doFinal and NoPadding Summary: Removed killSession() calls in certain impl classes when cancelling operations Reviewed-by: xuelei ! src/share/classes/sun/security/pkcs11/P11AEADCipher.java ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/P11Mac.java ! src/share/classes/sun/security/pkcs11/P11PSSSignature.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11Signature.java Changeset: ceb04c46a28d Author: andrew Date: 2020-11-05 02:46 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/ceb04c46a28d Added tag jdk8u275-b01 for changeset efb922cd7ac4 ! .hgtags Changeset: 9b8fdf354146 Author: andrew Date: 2020-11-05 05:11 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/9b8fdf354146 Added tag jdk8u275-ga for changeset efb922cd7ac4 ! .hgtags Changeset: 8c34cdbed6dc Author: andrew Date: 2020-11-06 03:40 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/8c34cdbed6dc Merge jdk8u275-b01 ! .hgtags Changeset: 86124418f5ea Author: andrew Date: 2020-11-06 03:45 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/86124418f5ea Added tag aarch64-shenandoah-jdk8u275-b01 for changeset 8c34cdbed6dc ! .hgtags Changeset: 3fbfec3d8646 Author: aleonard Date: 2020-08-20 05:16 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/3fbfec3d8646 8025936: Windows .pdb and .map files does not have proper dependencies setup Reviewed-by: andrew ! make/CompileLaunchers.gmk ! make/lib/CoreLibraries.gmk Changeset: 885f7ab464de Author: sgehwolf Date: 2020-08-28 12:15 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/885f7ab464de 8252395: [8u] --with-native-debug-symbols=external doesn't include debuginfo files for binaries Summary: ensure debuginfo files get properly copied to the images directory Reviewed-by: andrew, aph ! make/CompileLaunchers.gmk ! make/Images.gmk Changeset: 251407c9665e Author: akasko Date: 2020-09-09 17:24 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/251407c9665e 8051853: new URI("x/").resolve("..").getSchemeSpecificPart() returns null! Reviewed-by: andrew ! src/share/classes/java/net/URI.java ! test/java/net/URI/Test.java Changeset: 9abd5cc9a015 Author: psadhukhan Date: 2017-06-06 10:58 +0530 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/9abd5cc9a015 6962725: Regtest javax/swing/JFileChooser/6738668/bug6738668.java fails under Linux Reviewed-by: serb ! test/javax/swing/JFileChooser/6738668/bug6738668.java ! test/javax/swing/JFileChooser/6738668/security.policy Changeset: cb38ce41fab3 Author: serb Date: 2020-08-18 00:08 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/cb38ce41fab3 8251469: Better cleanup for test/jdk/javax/imageio/SetOutput.java Reviewed-by: prr, pbansal ! test/javax/imageio/SetOutput.java Changeset: dc3817b6e1d9 Author: sgehwolf Date: 2020-09-09 18:49 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/dc3817b6e1d9 8252975: [8u] JDK-8252395 breaks the build for --with-native-debug-symbols=internal Reviewed-by: zgu ! make/CompileLaunchers.gmk Changeset: ebda2b67b572 Author: prr Date: 2020-08-31 06:14 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/ebda2b67b572 8245400: Upgrade to LittleCMS 2.11 Reviewed-by: serb, jdv ! THIRD_PARTY_README ! src/share/native/sun/java2d/cmm/lcms/cmsalpha.c ! src/share/native/sun/java2d/cmm/lcms/cmscam02.c ! src/share/native/sun/java2d/cmm/lcms/cmscgats.c ! src/share/native/sun/java2d/cmm/lcms/cmscnvrt.c ! src/share/native/sun/java2d/cmm/lcms/cmserr.c ! src/share/native/sun/java2d/cmm/lcms/cmsgamma.c ! src/share/native/sun/java2d/cmm/lcms/cmsgmt.c ! src/share/native/sun/java2d/cmm/lcms/cmshalf.c ! src/share/native/sun/java2d/cmm/lcms/cmsintrp.c ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c ! src/share/native/sun/java2d/cmm/lcms/cmsio1.c ! src/share/native/sun/java2d/cmm/lcms/cmslut.c ! src/share/native/sun/java2d/cmm/lcms/cmsmd5.c ! src/share/native/sun/java2d/cmm/lcms/cmsmtrx.c ! src/share/native/sun/java2d/cmm/lcms/cmsnamed.c ! src/share/native/sun/java2d/cmm/lcms/cmsopt.c ! src/share/native/sun/java2d/cmm/lcms/cmspack.c ! src/share/native/sun/java2d/cmm/lcms/cmspcs.c ! src/share/native/sun/java2d/cmm/lcms/cmsplugin.c ! src/share/native/sun/java2d/cmm/lcms/cmsps2.c ! src/share/native/sun/java2d/cmm/lcms/cmssamp.c ! src/share/native/sun/java2d/cmm/lcms/cmssm.c ! src/share/native/sun/java2d/cmm/lcms/cmstypes.c ! src/share/native/sun/java2d/cmm/lcms/cmsvirt.c ! src/share/native/sun/java2d/cmm/lcms/cmswtpnt.c ! src/share/native/sun/java2d/cmm/lcms/cmsxform.c ! src/share/native/sun/java2d/cmm/lcms/lcms2.h ! src/share/native/sun/java2d/cmm/lcms/lcms2_internal.h ! src/share/native/sun/java2d/cmm/lcms/lcms2_plugin.h Changeset: aead2bc0cef3 Author: ljiang Date: 2020-08-07 01:48 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/aead2bc0cef3 8250665: Wrong translation for the month name of May in ar_JO,LB,SY Reviewed-by: naoto ! src/share/classes/sun/text/resources/ar/FormatData_ar_JO.java ! src/share/classes/sun/text/resources/ar/FormatData_ar_LB.java ! src/share/classes/sun/text/resources/ar/FormatData_ar_SY.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 0ecf39f74dcf Author: sgehwolf Date: 2020-08-26 11:46 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/0ecf39f74dcf 8252384: [TESTBUG] Some tests refer to COMPAT provider rather than JRE Summary: correct backported locale tests from COMPAT to JRE locale provider Reviewed-by: andrew Contributed-by: jdowland at redhat.com ! test/java/text/Format/DateFormat/Bug6530336.java ! test/java/text/Format/DateFormat/DateFormatRegression.java ! test/java/text/Format/DateFormat/DateFormatRoundTripTest.java ! test/java/text/Format/DateFormat/DateFormatTest.java ! test/java/text/Format/DateFormat/IntlTestDateFormat.java ! test/java/text/Format/DateFormat/IntlTestDateFormatAPI.java ! test/java/text/Format/DateFormat/IntlTestSimpleDateFormatAPI.java ! test/java/text/Format/DateFormat/NonGregorianFormatTest.java ! test/java/text/Format/DateFormat/TimeZoneNameTest.java ! test/java/text/Format/MessageFormat/LargeMessageFormat.java ! test/java/text/Format/NumberFormat/BigDecimalFormat.java ! test/java/text/Format/NumberFormat/BigDecimalParse.java ! test/java/text/Format/NumberFormat/Bug4838107.java ! test/java/text/Format/NumberFormat/NumberRegression.java ! test/java/text/Format/NumberFormat/NumberTest.java ! test/java/util/Calendar/JapanEraNameCompatTest.java ! test/java/util/TimeZone/HongKong.java ! test/java/util/TimeZone/TimeZoneRegression.java Changeset: 46754d3706d8 Author: aleonard Date: 2020-09-17 00:59 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/46754d3706d8 8207766: [testbug] Adapt tests for Aix. Reviewed-by: mdoerr, andrew ! test/ProblemList.txt ! test/com/sun/jdi/EvalArraysAsList.sh ! test/java/awt/Toolkit/Headless/WrappedToolkitTest/WrappedToolkitTest.sh ! test/sun/security/pkcs11/PKCS11Test.java ! test/sun/security/pkcs11/Secmod/TestNssDbSqlite.java Changeset: 177f01f5281d Author: andrew Date: 2020-09-18 06:41 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/177f01f5281d Merge Changeset: e99af2373c70 Author: andrew Date: 2020-09-18 06:43 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/e99af2373c70 Added tag jdk8u282-b00 for changeset 4546aa3faf37 ! .hgtags Changeset: 0036148c47ec Author: uvangapally Date: 2017-10-05 01:31 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/0036148c47ec 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument Summary: Added two new API's to limit the stack trace depth Reviewed-by: mchung, dfuchs, rriggs, egahlin Contributed-by: ujwal.vangapally at oracle.com ! src/share/classes/com/sun/management/ThreadMXBean.java ! src/share/classes/sun/management/ThreadImpl.java ! src/share/javavm/export/jmm.h ! src/share/native/sun/management/ThreadImpl.c + test/com/sun/management/ThreadMXBean/MaxDepthForThreadInfoTest.java Changeset: 49e7d9293ee5 Author: ssadetsky Date: 2016-09-30 22:10 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/49e7d9293ee5 8132664: closed/javax/swing/DataTransfer/DefaultNoDrop/DefaultNoDrop.java locks on Windows Reviewed-by: serb ! src/windows/native/sun/windows/awt_DnDDS.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h Changeset: 52db4375e77d Author: andrew Date: 2020-09-26 19:40 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/52db4375e77d 8253550: [8u] JDK-8252395 breaks the build for make STRIP_POLICY=no_strip Summary: Add check that STRIP_POLICY is not no_strip before attempting to reference stripped debuginfo Reviewed-by: aph, sgehwolf ! make/CompileLaunchers.gmk Changeset: e148a6a0b505 Author: phh Date: 2019-09-25 15:22 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/e148a6a0b505 8231209: [REDO] ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread Summary: Add com.sun.management.getCurrentThreadAllocatedBytes, implement getThreadAllocatedBytes(long) independent of getThreadAllocatedBytes(long[]) Reviewed-by: mchung, dholmes, sspitsyn ! make/mapfiles/libmanagement/mapfile-vers ! src/share/classes/com/sun/management/ThreadMXBean.java ! src/share/classes/java/lang/management/ThreadMXBean.java ! src/share/classes/sun/management/ThreadImpl.java ! src/share/javavm/export/jmm.h ! src/share/native/sun/management/ThreadImpl.c ! test/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java Changeset: 59d320b277b8 Author: phh Date: 2019-10-23 18:43 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/59d320b277b8 8231968: getCurrentThreadAllocatedBytes default implementation s/b getThreadAllocatedBytes Summary: Pass Thread.currentThread().getId() to getThreadAllocatedBytes, remove its implSpec Reviewed-by: dholmes, mchung, sspitsyn ! src/share/classes/com/sun/management/ThreadMXBean.java Changeset: 01507675333b Author: apetushkov Date: 2020-10-01 18:06 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/01507675333b 8252904: VM crashes when JFR is used and JFR event class is transformed Reviewed-by: adinn + test/jdk/jfr/javaagent/Test8252904.java Changeset: 4cbe9a507526 Author: aghaisas Date: 2016-04-19 13:00 +0530 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/4cbe9a507526 8031423: Test java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java fails by Timeout on Windows Reviewed-by: yan, arapte ! test/java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java Changeset: 70eb29de84c2 Author: bpb Date: 2020-10-08 10:44 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/70eb29de84c2 8202076: test/jdk/java/io/File/WinSpecialFiles.java on windows with VS2017 Summary: If all other means to obtain the file length fail, fall back to FindFirstFile Reviewed-by: igerasim, alanb, zgu ! src/windows/native/java/io/WinNTFileSystem_md.c ! test/java/io/File/WinSpecialFiles.java Changeset: 9bdb41038765 Author: rhalade Date: 2020-08-29 13:55 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/9bdb41038765 8249176: Update GlobalSignR6CA test certificates Reviewed-by: xuelei ! test/security/infra/java/security/cert/CertPathValidator/certification/GlobalSignR6CA.java Changeset: 90605ff5af02 Author: darcy Date: 2016-02-03 12:52 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/90605ff5af02 8148916: Mark bug6400879.java as intermittently failing Reviewed-by: serb ! test/javax/sound/sampled/DirectAudio/bug6400879.java Changeset: d8aa6583f4b2 Author: darcy Date: 2016-02-03 13:56 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/d8aa6583f4b2 8148983: Fix extra comma in changes for JDK-8148916 Reviewed-by: jjg ! test/javax/sound/sampled/DirectAudio/bug6400879.java Changeset: d5f0a0cfa7b2 Author: darcy Date: 2015-08-27 18:12 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/d5f0a0cfa7b2 8134632: Mark javax/sound/midi/Devices/InitializationHang.java as headful Reviewed-by: prr ! test/javax/sound/midi/Devices/InitializationHang.java Changeset: 594f35a9d297 Author: mseledtsov Date: 2019-03-07 12:15 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/594f35a9d297 8213448: [TESTBUG] enhance jfr/jvm/TestDumpOnCrash Summary: added 2 more crash scenarios, removed dumponexit, and more Reviewed-by: egahlin ! test/jdk/jfr/jvm/TestDumpOnCrash.java Changeset: 9c7d7bcc74f7 Author: egahlin Date: 2019-06-13 12:27 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/9c7d7bcc74f7 8220657: JFR.dump does not work when filename is set Reviewed-by: ysuenaga ! src/share/classes/jdk/jfr/internal/PlatformRecording.java ! src/share/classes/jdk/jfr/internal/dcmd/DCmdDump.java + test/jdk/jfr/jcmd/TestJcmdDumpWithFileName.java Changeset: bf6928a82d07 Author: dongbohe Date: 2020-10-09 22:22 +0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/bf6928a82d07 8253752: test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.java fails randomly Reviewed-by: zgu, sgehwolf Contributed-by: xiezhaokun at huawei.com ! test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.java Changeset: 868b6a572018 Author: rhalade Date: 2020-10-06 16:38 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/868b6a572018 8254081: java/security/cert/PolicyNode/GetPolicyQualifiers.java fails due to an expired certificate Summary: Perform backdated validation of test certificate. Reviewed-by: mullan, xuelei ! test/java/security/cert/PolicyNode/GetPolicyQualifiers.java Changeset: e7ab0cde39a6 Author: aniyogi Date: 2016-07-20 11:25 +0530 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/e7ab0cde39a6 8160438: javax/swing/plaf/nimbus/8057791/bug8057791.java fails Reviewed-by: alexsch, rchamyal ! test/javax/swing/plaf/nimbus/8057791/bug8057791.java Changeset: 0815a27d5095 Author: sgehwolf Date: 2020-10-20 19:06 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/0815a27d5095 8255003: Build failures on Solaris Summary: Produce separate map file for linux Reviewed-by: bae, andrew ! make/lib/CoreLibraries.gmk + make/mapfiles/libjava/mapfile-linux ! make/mapfiles/libjava/mapfile-vers Changeset: 3607ed88c07b Author: sgehwolf Date: 2020-10-22 10:21 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/3607ed88c07b 8251840: Java_sun_awt_X11_XToolkit_getDefaultScreenData should not be in make/mapfiles/libawt_xawt/mapfile-vers Summary: Remove left-over map file entry Reviewed-by: bae, neugens, shade Contributed-by: Peter Tribble ! make/mapfiles/libawt_xawt/mapfile-vers Changeset: e2679aeb0a03 Author: dongbohe Date: 2020-10-22 19:52 +0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/e2679aeb0a03 8254683: [TEST_BUG] jdk/test/sun/tools/jconsole/WorkerDeadlockTest.java fails Reviewed-by: sgehwolf Contributed-by: xiezhaokun at huawei.com ! test/sun/tools/jconsole/ResourceCheckTest.java ! test/sun/tools/jconsole/ResourceCheckTest.sh ! test/sun/tools/jconsole/WorkerDeadlockTest.java + test/sun/tools/jconsole/WorkerDeadlockTest.sh + test/sun/tools/jconsole/common.sh Changeset: c6ae21e85948 Author: ssahoo Date: 2020-05-04 23:07 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/c6ae21e85948 8242335: Additional Tests for RSASSA-PSS Summary: New Tests for RSASSA-PSS Reviewed-by: valeriep + test/sun/security/rsa/pss/PSSKeyCompatibility.java + test/sun/security/rsa/pss/SerializedPSSKey.java Changeset: bea30964206d Author: mseledtsov Date: 2019-03-26 13:25 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/bea30964206d 8221342: [TESTBUG] Generate Dockerfile for docker testing Summary: Dockerfile is generated; introduced properties to specify custom base image Reviewed-by: sgehwolf, dholmes, jiefu - test/jdk/internal/platform/docker/Dockerfile-BasicTest - test/jdk/internal/platform/docker/Dockerfile-BasicTest-aarch64 - test/jdk/internal/platform/docker/Dockerfile-BasicTest-ppc64le - test/jdk/internal/platform/docker/Dockerfile-BasicTest-s390x ! test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java + test/lib/jdk/test/lib/containers/docker/DockerfileConfig.java Changeset: 7d340f9003ac Author: bobv Date: 2019-06-24 11:49 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/7d340f9003ac 8224502: [TESTBUG] JDK docker test TestSystemMetrics.java fails with access issues and OOM Reviewed-by: sgehwolf, mseledtsov ! test/jdk/internal/platform/docker/TestSystemMetrics.java ! test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java Changeset: 83a871b11965 Author: valeriep Date: 2020-10-30 07:09 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/83a871b11965 8236512: PKCS11 Connection closed after Cipher.doFinal and NoPadding Summary: Removed killSession() calls in certain impl classes when cancelling operations Reviewed-by: xuelei ! src/share/classes/sun/security/pkcs11/P11AEADCipher.java ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/P11Mac.java ! src/share/classes/sun/security/pkcs11/P11PSSSignature.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11Signature.java Changeset: 02c33fe5cb4c Author: yan Date: 2020-08-31 12:26 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/02c33fe5cb4c 8252497: Incorrect numeric currency code for ROL Reviewed-by: naoto ! src/share/classes/java/util/CurrencyData.properties Changeset: 81b41636e5d3 Author: mbaesken Date: 2019-11-18 16:49 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/81b41636e5d3 8234339: replace JLI_StrTok in java_md_solinux.c Reviewed-by: clanger, rriggs ! src/share/bin/jli_util.h ! src/solaris/bin/java_md_solinux.c Changeset: c7d1858793a8 Author: dmarkov Date: 2020-10-30 07:27 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/c7d1858793a8 8232114: JVM crashed at imjpapi.dll in native code Reviewed-by: serb, alitvinov, andrew ! src/windows/native/sun/windows/awt_InputMethod.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h Changeset: 88ff3523c9ff Author: yan Date: 2020-08-31 12:26 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/88ff3523c9ff 8252497: Incorrect numeric currency code for ROL Reviewed-by: naoto ! src/share/classes/java/util/CurrencyData.properties Changeset: eeec2fa855fa Author: andrew Date: 2020-10-30 07:34 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/eeec2fa855fa Merge Changeset: 96b9be69735b Author: andrew Date: 2020-10-30 08:02 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/96b9be69735b Merge ! .hgtags Changeset: 4f8e8e18c901 Author: xuelei Date: 2019-11-06 09:45 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/4f8e8e18c901 8223940: Private key not supported by chosen signature algorithm Reviewed-by: valeriep ! src/share/classes/sun/security/ssl/CertificateVerify.java ! src/share/classes/sun/security/ssl/DHServerKeyExchange.java ! src/share/classes/sun/security/ssl/ECDHServerKeyExchange.java ! src/share/classes/sun/security/ssl/SignatureScheme.java Changeset: 93840580183a Author: andrew Date: 2020-10-27 18:23 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/93840580183a 8254177: (tz) Upgrade time-zone data to tzdata2020b Summary: Remove obsolete systemv & pacificnew files and US/Pacific-New zone Reviewed-by: martin ! make/data/tzdata/VERSION ! make/data/tzdata/africa ! make/data/tzdata/antarctica ! make/data/tzdata/asia ! make/data/tzdata/australasia ! make/data/tzdata/europe ! make/data/tzdata/leapseconds ! make/data/tzdata/northamerica - make/data/tzdata/pacificnew ! make/data/tzdata/southamerica - make/data/tzdata/systemv ! make/gendata/GendataTZDB.gmk ! src/aix/lib/tzmappings ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java ! test/sun/util/calendar/zi/TestZoneInfo310.java ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/africa ! test/sun/util/calendar/zi/tzdata/antarctica ! test/sun/util/calendar/zi/tzdata/asia ! test/sun/util/calendar/zi/tzdata/australasia ! test/sun/util/calendar/zi/tzdata/europe ! test/sun/util/calendar/zi/tzdata/leapseconds ! test/sun/util/calendar/zi/tzdata/northamerica - test/sun/util/calendar/zi/tzdata/pacificnew ! test/sun/util/calendar/zi/tzdata/southamerica - test/sun/util/calendar/zi/tzdata/systemv Changeset: e371df07f682 Author: robm Date: 2019-01-10 07:54 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/e371df07f682 8214440: ldap over a TLS connection negotiate failed with "javax.net.ssl.SSLPeerUnverifiedException: hostname of the server '' does not match the hostname in the server's certificate" Reviewed-by: vtewari, xuelei ! src/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java Changeset: b5ab70828d87 Author: valeriep Date: 2020-02-12 02:44 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/b5ab70828d87 8238448: RSASSA-PSS signature verification fail when using certain odd key sizes Summary: Calculate and set offset for correct verification for such key sizes Reviewed-by: xuelei ! src/share/classes/sun/security/rsa/RSAPSSSignature.java ! test/sun/security/rsa/pss/SignatureTest2.java ! test/sun/security/rsa/pss/SignatureTestPSS.java Changeset: 7689430fcf1c Author: andrew Date: 2020-10-30 20:53 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/7689430fcf1c Merge Changeset: 4c5dceabd4c6 Author: yan Date: 2014-04-21 14:35 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/4c5dceabd4c6 8039279: Move awt tests to openjdk repository Reviewed-by: pchelko, alexsch Contributed-by: Dmitriy Ermashov + test/java/awt/Frame/SetMaximizedBounds/SetMaximizedBounds.java + test/java/awt/GridLayout/ChangeGridSize/ChangeGridSize.java + test/java/awt/GridLayout/ComponentPreferredSize/ComponentPreferredSize.java + test/java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java + test/java/awt/Toolkit/LockingKeyStateTest/LockingKeyStateTest.java Changeset: 2cecd9cb015e Author: andrew Date: 2020-11-03 05:58 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/2cecd9cb015e Added tag jdk8u282-b01 for changeset 4c5dceabd4c6 ! .hgtags Changeset: 7c38a265c138 Author: andrew Date: 2020-12-07 02:25 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/7c38a265c138 Merge jdk8u282-b01 ! .hgtags ! THIRD_PARTY_README ! make/CompileLaunchers.gmk ! make/Images.gmk ! make/data/tzdata/VERSION ! make/data/tzdata/africa ! make/data/tzdata/antarctica ! make/data/tzdata/asia ! make/data/tzdata/australasia ! make/data/tzdata/europe ! make/data/tzdata/leapseconds ! make/data/tzdata/northamerica - make/data/tzdata/pacificnew ! make/data/tzdata/southamerica - make/data/tzdata/systemv ! make/lib/CoreLibraries.gmk ! make/mapfiles/libawt_xawt/mapfile-vers ! make/mapfiles/libjava/mapfile-vers ! make/mapfiles/libmanagement/mapfile-vers ! src/share/classes/com/sun/management/ThreadMXBean.java ! src/share/classes/java/lang/management/ThreadMXBean.java ! src/share/classes/java/net/URI.java ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java ! src/share/javavm/export/jmm.h ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c ! src/share/native/sun/java2d/cmm/lcms/cmslut.c ! src/solaris/bin/java_md_solinux.c ! src/windows/native/sun/windows/awt_DnDDS.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp ! test/ProblemList.txt ! test/java/awt/Toolkit/Headless/WrappedToolkitTest/WrappedToolkitTest.sh ! test/javax/sound/sampled/DirectAudio/bug6400879.java - test/jdk/internal/platform/docker/Dockerfile-BasicTest - test/jdk/internal/platform/docker/Dockerfile-BasicTest-aarch64 - test/jdk/internal/platform/docker/Dockerfile-BasicTest-ppc64le - test/jdk/internal/platform/docker/Dockerfile-BasicTest-s390x ! test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/africa ! test/sun/util/calendar/zi/tzdata/antarctica ! test/sun/util/calendar/zi/tzdata/asia ! test/sun/util/calendar/zi/tzdata/australasia ! test/sun/util/calendar/zi/tzdata/europe ! test/sun/util/calendar/zi/tzdata/leapseconds ! test/sun/util/calendar/zi/tzdata/northamerica - test/sun/util/calendar/zi/tzdata/pacificnew ! test/sun/util/calendar/zi/tzdata/southamerica - test/sun/util/calendar/zi/tzdata/systemv Changeset: 6971dedd8a15 Author: andrew Date: 2020-12-07 02:28 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/6971dedd8a15 Added tag aarch64-shenandoah-jdk8u282-b01 for changeset 7c38a265c138 ! .hgtags Changeset: 3d2b77f2c2fd Author: andrew Date: 2020-11-16 13:36 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/3d2b77f2c2fd Merge ! .hgtags - make/data/tzdata/pacificnew - make/data/tzdata/systemv - test/jdk/internal/platform/docker/Dockerfile-BasicTest - test/jdk/internal/platform/docker/Dockerfile-BasicTest-aarch64 - test/jdk/internal/platform/docker/Dockerfile-BasicTest-ppc64le - test/jdk/internal/platform/docker/Dockerfile-BasicTest-s390x - test/sun/util/calendar/zi/tzdata/pacificnew - test/sun/util/calendar/zi/tzdata/systemv Changeset: 1c64ca5020d9 Author: andrew Date: 2020-11-18 06:55 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/1c64ca5020d9 Added tag jdk8u282-b02 for changeset 3d2b77f2c2fd ! .hgtags Changeset: 894859a74413 Author: andrew Date: 2020-12-16 04:19 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/894859a74413 Merge jdk8u282-b02 ! .hgtags Changeset: ead54d9d0710 Author: andrew Date: 2020-12-16 04:19 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/ead54d9d0710 Added tag aarch64-shenandoah-jdk8u282-b02 for changeset 894859a74413 ! .hgtags Changeset: d6c70b35a57c Author: yan Date: 2014-04-29 14:32 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/d6c70b35a57c 8041592: [TEST_BUG] Move 42 AWT hw/lw mixing tests to jdk Reviewed-by: anthony, pchelko + test/java/awt/Mixing/AWT_Mixing/FrameBorderCounter.java + test/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java + test/java/awt/Mixing/AWT_Mixing/HierarchyBoundsListenerMixingTest.java + test/java/awt/Mixing/AWT_Mixing/JButtonInGlassPaneOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JButtonOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JColorChooserOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JEditorPaneInGlassPaneOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JEditorPaneOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JGlassPaneInternalFrameOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JGlassPaneMoveOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JInternalFrameMoveOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JInternalFrameOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JLabelInGlassPaneOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JLabelOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JListInGlassPaneOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JListOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JPanelInGlassPaneOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JPanelOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JProgressBarInGlassPaneOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JProgressBarOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JScrollBarInGlassPaneOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JScrollBarOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JScrollPaneOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JSliderInGlassPaneOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JSliderOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JSpinnerInGlassPaneOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JSpinnerOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JTableOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JTextAreaInGlassPaneOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JTextAreaOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JTextFieldInGlassPaneOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JTextFieldOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JToggleButtonInGlassPaneOverlapping.java + test/java/awt/Mixing/AWT_Mixing/JToggleButtonOverlapping.java + test/java/awt/Mixing/AWT_Mixing/MixingFrameResizing.java + test/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java + test/java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java + test/java/awt/Mixing/AWT_Mixing/OpaqueOverlappingChoice.java + test/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java + test/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java + test/java/awt/Mixing/AWT_Mixing/Util.java + test/java/awt/Mixing/AWT_Mixing/ViewportOverlapping.java Changeset: a49b0afd5ef6 Author: alexsch Date: 2014-02-24 17:23 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/a49b0afd5ef6 8008657: JSpinner setComponentOrientation doesn't affect on text orientation Reviewed-by: malenkov, serb Contributed-by: jdowland at redhat.com ! src/share/classes/javax/swing/JSpinner.java ! src/share/classes/javax/swing/plaf/basic/BasicSpinnerUI.java + test/javax/swing/JSpinner/8008657/bug8008657.java Changeset: b26ef40d856f Author: clanger Date: 2020-11-01 23:24 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/b26ef40d856f 8255603: Memory/Performance regression after JDK-8210985 Reviewed-by: simonis, xuelei, aph ! src/share/classes/sun/security/util/Cache.java Changeset: 4edfcb2d8920 Author: pkbalakr Date: 2016-10-27 10:49 +0530 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/4edfcb2d8920 8168292: [TESTBUG] [macosx] Test java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X Reviewed-by: psadhukhan, aghaisas ! test/java/awt/TrayIcon/DragEventSource/DragEventSource.java Changeset: 405383f2967d Author: serb Date: 2019-12-18 10:10 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/405383f2967d 8223108: Test java/awt/EventQueue/NonComponentSourcePost.java is unstable Reviewed-by: prr + test/java/awt/EventQueue/NonComponentSourcePost.java Changeset: 03919285fccc Author: mchung Date: 2018-02-12 11:40 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/03919285fccc 8168682: jdk/test/java/lang/ClassLoader/forNameLeak/ClassForNameLeak.java fails with -Xcomp Reviewed-by: bchristi ! test/java/lang/ClassLoader/forNameLeak/ClassForNameLeak.java ! test/java/lang/ClassLoader/forNameLeak/test.policy Changeset: 3317411444d6 Author: aniyogi Date: 2016-08-25 13:46 +0530 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/3317411444d6 8163161: [PIT][TEST_BUG] increase timeout in javax/swing/plaf/nimbus/8057791/bug8057791.java Reviewed-by: alexsch, rchamyal ! test/javax/swing/plaf/nimbus/8057791/bug8057791.java Changeset: 23add259af02 Author: andrew Date: 2020-11-24 05:05 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/23add259af02 Merge Changeset: aa019b2b9e42 Author: andrew Date: 2020-11-24 05:05 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/aa019b2b9e42 Added tag jdk8u282-b03 for changeset 23add259af02 ! .hgtags Changeset: 0d6971386b8e Author: andrew Date: 2020-12-29 22:39 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/0d6971386b8e Merge jdk8u282-b03 ! .hgtags ! src/share/classes/javax/swing/JSpinner.java Changeset: 139e034f7fd8 Author: andrew Date: 2020-12-29 22:39 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/139e034f7fd8 Added tag aarch64-shenandoah-jdk8u282-b03 for changeset 0d6971386b8e ! .hgtags Changeset: 97666ac085c5 Author: aleonard Date: 2020-11-20 15:02 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/97666ac085c5 8256752: 8252395 incorrect copy rule for macos .dSYM folder Reviewed-by: sgehwolf ! make/CompileLaunchers.gmk Changeset: aefa283b6740 Author: mseledtsov Date: 2019-04-04 12:29 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/aefa283b6740 8221710: [TESTBUG] more configurable parameters for docker testing Summary: Introduced docker test config properties Reviewed-by: lmesnik, iignatyev, egahlin, phh ! test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java Changeset: 02ed0906dd82 Author: weijun Date: 2018-09-11 08:48 +0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/02ed0906dd82 8205507: jdk/javax/xml/crypto/dsig/GenerationTests.java timed out Reviewed-by: mullan ! test/javax/xml/crypto/dsig/GenerationTests.java Changeset: f1405f818b74 Author: avstepan Date: 2014-07-08 16:01 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/f1405f818b74 8043126: move awt automated functional tests from AWT_Events/Lw and AWT_Events/AWT to OpenJDK repository Reviewed-by: pchelko + test/java/awt/event/KeyEvent/ExtendedModifiersTest/ExtendedModifiersTest.java + test/java/awt/event/KeyEvent/KeyMaskTest/KeyMaskTest.java + test/java/awt/event/MouseEvent/MouseButtonsAndKeyMasksTest/MouseButtonsAndKeyMasksTest.java + test/java/awt/event/MouseEvent/MouseButtonsTest/MouseButtonsTest.java + test/java/awt/event/MouseEvent/MultipleMouseButtonsTest/MultipleMouseButtonsTest.java + test/java/awt/event/helpers/lwcomponents/LWButton.java + test/java/awt/event/helpers/lwcomponents/LWComponent.java + test/java/awt/event/helpers/lwcomponents/LWList.java Changeset: c358b3fc7d8d Author: yan Date: 2014-07-01 12:49 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/c358b3fc7d8d 8043131: Move ShapedAndTranslucentWindows and GC functional AWT tests to regression tree Reviewed-by: pchelko Contributed-by: Dmitriy Ermashov + test/java/awt/Frame/DisposeParentGC/DisposeParentGC.java + test/java/awt/Frame/FramesGC/FramesGC.java ! test/java/awt/Window/ShapedAndTranslucentWindows/FocusAWTTest.java + test/java/awt/Window/ShapedAndTranslucentWindows/SetShape.java + test/java/awt/Window/ShapedAndTranslucentWindows/SetShapeAndClick.java + test/java/awt/Window/ShapedAndTranslucentWindows/SetShapeDynamicallyAndClick.java ! test/java/awt/Window/ShapedAndTranslucentWindows/Shaped.java ! test/java/awt/Window/ShapedAndTranslucentWindows/ShapedByAPI.java ! test/java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java + test/java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucentWindowClick.java ! test/java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java ! test/java/awt/Window/ShapedAndTranslucentWindows/Translucent.java + test/java/awt/Window/ShapedAndTranslucentWindows/TranslucentChoice.java + test/java/awt/Window/ShapedAndTranslucentWindows/TranslucentWindowClick.java Changeset: aa009486958d Author: yan Date: 2014-06-04 17:24 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/aa009486958d 8044157: [TEST_BUG] Improve recently submitted AWT_Mixing tests Reviewed-by: pchelko ! test/java/awt/Mixing/AWT_Mixing/FrameBorderCounter.java ! test/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java ! test/java/awt/Mixing/AWT_Mixing/HierarchyBoundsListenerMixingTest.java ! test/java/awt/Mixing/AWT_Mixing/JButtonInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JButtonOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JColorChooserOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JEditorPaneInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JEditorPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JGlassPaneInternalFrameOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JGlassPaneMoveOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JInternalFrameMoveOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JInternalFrameOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JLabelInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JLabelOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JListInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JListOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JPanelInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JPanelOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JProgressBarInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JProgressBarOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JScrollBarInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JScrollBarOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JScrollPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JSliderInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JSliderOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JSpinnerInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JSpinnerOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTableOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTextAreaInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTextAreaOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTextFieldInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTextFieldOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JToggleButtonInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JToggleButtonOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/MixingFrameResizing.java ! test/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java ! test/java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/OpaqueOverlappingChoice.java ! test/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java ! test/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java ! test/java/awt/Mixing/AWT_Mixing/ViewportOverlapping.java Changeset: 43963300a257 Author: yan Date: 2014-05-30 14:23 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/43963300a257 8044172: [TEST_BUG] Move regtests for 4523758 and AltPlusNumberKeyCombinationsTest to jdk Reviewed-by: pchelko + test/java/awt/keyboard/AltPlusNumberKeyCombinationsTest/AltPlusNumberKeyCombinationsTest.java + test/javax/swing/JComboBox/4523758/bug4523758.java Changeset: 55d9fa4e01c7 Author: yan Date: 2014-06-19 12:44 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/55d9fa4e01c7 8044429: move awt automated tests for AWT_Modality to OpenJDK repository Reviewed-by: pchelko Contributed-by: Alexander Stepanov + test/java/awt/Modal/ModalExclusionTests/ApplicationExcludeDialogFileTest.java + test/java/awt/Modal/ModalExclusionTests/ApplicationExcludeDialogPageSetupTest.java + test/java/awt/Modal/ModalExclusionTests/ApplicationExcludeDialogPrintSetupTest.java + test/java/awt/Modal/ModalExclusionTests/ApplicationExcludeFrameFileTest.java + test/java/awt/Modal/ModalExclusionTests/ApplicationExcludeFramePageSetupTest.java + test/java/awt/Modal/ModalExclusionTests/ApplicationExcludeFramePrintSetupTest.java + test/java/awt/Modal/ModalExclusionTests/ExcludeDialogTest.java + test/java/awt/Modal/ModalExclusionTests/ExcludeFrameTest.java + test/java/awt/Modal/ModalExclusionTests/ToolkitExcludeDialogFileTest.java + test/java/awt/Modal/ModalExclusionTests/ToolkitExcludeDialogPageSetupTest.java + test/java/awt/Modal/ModalExclusionTests/ToolkitExcludeDialogPrintSetupTest.java + test/java/awt/Modal/ModalExclusionTests/ToolkitExcludeFrameFileTest.java + test/java/awt/Modal/ModalExclusionTests/ToolkitExcludeFramePageSetupTest.java + test/java/awt/Modal/ModalExclusionTests/ToolkitExcludeFramePrintSetupTest.java + test/java/awt/Modal/helpers/Flag.java + test/java/awt/Modal/helpers/TestDialog.java + test/java/awt/Modal/helpers/TestFrame.java + test/java/awt/Modal/helpers/TestWindow.java Changeset: 9e07586d8a09 Author: yan Date: 2014-06-20 16:48 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/9e07586d8a09 8047180: Move functional tests AWT_Headless/Automated to OpenJDK repository Reviewed-by: pchelko, alexsch Contributed-by: Dmitriy Ermashov + test/java/awt/AlphaComposite/HeadlessAlphaComposite.java + test/java/awt/Color/HeadlessColor.java + test/java/awt/Component/Headless/HeadlessButton.java + test/java/awt/Component/Headless/HeadlessCanvas.java + test/java/awt/Component/Headless/HeadlessCheckbox.java + test/java/awt/Component/Headless/HeadlessChoice.java + test/java/awt/Component/Headless/HeadlessComponent.java + test/java/awt/Component/Headless/HeadlessContainer.java + test/java/awt/Component/Headless/HeadlessDialog.java + test/java/awt/Component/Headless/HeadlessFileDialog.java + test/java/awt/Component/Headless/HeadlessFrame.java + test/java/awt/Component/Headless/HeadlessLabel.java + test/java/awt/Component/Headless/HeadlessList.java + test/java/awt/Component/Headless/HeadlessPanel.java + test/java/awt/Component/Headless/HeadlessScrollPane.java + test/java/awt/Component/Headless/HeadlessScrollbar.java + test/java/awt/Component/Headless/HeadlessTextArea.java + test/java/awt/Component/Headless/HeadlessTextField.java + test/java/awt/Component/Headless/HeadlessWindow.java + test/java/awt/Cursor/HeadlessCursor.java + test/java/awt/EventQueue/HeadlessEventQueue.java + test/java/awt/Focus/Headless/HeadlessContainerOrderFocusTraversalPolicy.java + test/java/awt/Focus/Headless/HeadlessDefaultFocusTraversalPolicy.java + test/java/awt/Focus/Headless/HeadlessDefaultKeyboardFocusManager.java + test/java/awt/FontClass/HeadlessFont.java + test/java/awt/GradientPaint/HeadlessGradientPaint.java + test/java/awt/Graphics2D/Headless/HeadlessPoint.java + test/java/awt/Graphics2D/Headless/HeadlessPolygon.java + test/java/awt/Graphics2D/Headless/HeadlessRectangle.java + test/java/awt/GraphicsConfiguration/HeadlessGraphicsConfiguration.java + test/java/awt/GraphicsDevice/HeadlessGraphicsDevice.java + test/java/awt/GraphicsEnvironment/HeadlessGraphicsEnvironment.java + test/java/awt/Headless/HeadlessAWTEventMulticaster.java + test/java/awt/Headless/HeadlessAWTException.java + test/java/awt/Headless/HeadlessBasicStroke.java + test/java/awt/Headless/HeadlessBorderLayout.java + test/java/awt/Headless/HeadlessCardLayout.java + test/java/awt/Headless/HeadlessCheckboxGroup.java + test/java/awt/Headless/HeadlessCheckboxMenuItem.java + test/java/awt/Headless/HeadlessComponentOrientation.java + test/java/awt/Headless/HeadlessDimension.java + test/java/awt/Headless/HeadlessFlowLayout.java + test/java/awt/Headless/HeadlessMediaTracker.java + test/java/awt/Headless/HeadlessPopupMenu.java + test/java/awt/Insets/HeadlessInsets.java + test/java/awt/Menu/Headless/HeadlessMenu.java + test/java/awt/Menu/Headless/HeadlessMenuItem.java + test/java/awt/Menu/Headless/HeadlessMenuShortcut.java + test/java/awt/MenuBar/HeadlessMenuBar.java + test/java/awt/Toolkit/Headless/HeadlessToolkit.java + test/java/awt/applet/Applet/HeadlessApplet.java + test/java/awt/datatransfer/Headless/HeadlessClipboard.java + test/java/awt/datatransfer/Headless/HeadlessDataFlavor.java + test/java/awt/datatransfer/Headless/HeadlessSystemFlavorMap.java + test/java/awt/im/Headless/HeadlessInputContext.java + test/java/awt/im/Headless/HeadlessInputMethodHighlight.java + test/java/awt/image/Headless/HeadlessAffineTransformOp.java + test/java/awt/image/Headless/HeadlessAreaAveragingScaleFilter.java + test/java/awt/image/Headless/HeadlessBufferedImage.java + test/java/awt/image/Headless/HeadlessBufferedImageFilter.java + test/java/awt/image/Headless/HeadlessColorModel.java + test/java/awt/image/Headless/HeadlessCropImageFilter.java + test/java/awt/image/Headless/HeadlessImageFilter.java + test/java/awt/image/Headless/HeadlessIndexColorModel.java + test/java/awt/image/Headless/HeadlessRGBImageFilter.java + test/java/awt/image/Headless/HeadlessReplicateScaleFilter.java + test/java/awt/print/Headless/HeadlessBook.java + test/java/awt/print/Headless/HeadlessPageFormat.java + test/java/awt/print/Headless/HeadlessPaper.java + test/java/awt/print/Headless/HeadlessPrinterJob.java + test/javax/swing/Headless/HeadlessAbstractSpinnerModel.java + test/javax/swing/Headless/HeadlessBox.java + test/javax/swing/Headless/HeadlessBox_Filler.java + test/javax/swing/Headless/HeadlessCellRendererPane.java + test/javax/swing/Headless/HeadlessDefaultListCellRenderer.java + test/javax/swing/Headless/HeadlessDefaultListCellRenderer_UIResource.java + test/javax/swing/Headless/HeadlessGrayFilter.java + test/javax/swing/Headless/HeadlessJApplet.java + test/javax/swing/Headless/HeadlessJButton.java + test/javax/swing/Headless/HeadlessJCheckBox.java + test/javax/swing/Headless/HeadlessJCheckBoxMenuItem.java + test/javax/swing/Headless/HeadlessJColorChooser.java + test/javax/swing/Headless/HeadlessJComboBox.java + test/javax/swing/Headless/HeadlessJComponent.java + test/javax/swing/Headless/HeadlessJDesktopPane.java + test/javax/swing/Headless/HeadlessJDialog.java + test/javax/swing/Headless/HeadlessJEditorPane.java + test/javax/swing/Headless/HeadlessJFileChooser.java + test/javax/swing/Headless/HeadlessJFormattedTextField.java + test/javax/swing/Headless/HeadlessJFrame.java + test/javax/swing/Headless/HeadlessJInternalFrame.java + test/javax/swing/Headless/HeadlessJInternalFrame_JDesktopIcon.java + test/javax/swing/Headless/HeadlessJLabel.java + test/javax/swing/Headless/HeadlessJLayeredPane.java + test/javax/swing/Headless/HeadlessJList.java + test/javax/swing/Headless/HeadlessJMenu.java + test/javax/swing/Headless/HeadlessJMenuBar.java + test/javax/swing/Headless/HeadlessJMenuItem.java + test/javax/swing/Headless/HeadlessJOptionPane.java + test/javax/swing/Headless/HeadlessJPanel.java + test/javax/swing/Headless/HeadlessJPasswordField.java + test/javax/swing/Headless/HeadlessJPopupMenu.java + test/javax/swing/Headless/HeadlessJPopupMenu_Separator.java + test/javax/swing/Headless/HeadlessJProgressBar.java + test/javax/swing/Headless/HeadlessJRadioButton.java + test/javax/swing/Headless/HeadlessJRadioButtonMenuItem.java + test/javax/swing/Headless/HeadlessJRootPane.java + test/javax/swing/Headless/HeadlessJScrollBar.java + test/javax/swing/Headless/HeadlessJScrollPane.java + test/javax/swing/Headless/HeadlessJSeparator.java + test/javax/swing/Headless/HeadlessJSlider.java + test/javax/swing/Headless/HeadlessJSpinner.java + test/javax/swing/Headless/HeadlessJSplitPane.java + test/javax/swing/Headless/HeadlessJTabbedPane.java + test/javax/swing/Headless/HeadlessJTable.java + test/javax/swing/Headless/HeadlessJTextArea.java + test/javax/swing/Headless/HeadlessJTextField.java + test/javax/swing/Headless/HeadlessJTextPane.java + test/javax/swing/Headless/HeadlessJToggleButton.java + test/javax/swing/Headless/HeadlessJToolBar.java + test/javax/swing/Headless/HeadlessJToolBar_Separator.java + test/javax/swing/Headless/HeadlessJToolTip.java + test/javax/swing/Headless/HeadlessJTree.java + test/javax/swing/Headless/HeadlessJViewport.java + test/javax/swing/Headless/HeadlessJWindow.java + test/javax/swing/Headless/HeadlessLookAndFeel.java + test/javax/swing/Headless/HeadlessMenuSelectionManager.java + test/javax/swing/Headless/HeadlessOverlayLayout.java + test/javax/swing/Headless/HeadlessPopupFactory.java + test/javax/swing/Headless/HeadlessScrollPaneLayout.java + test/javax/swing/Headless/HeadlessSizeRequirements.java + test/javax/swing/Headless/HeadlessSizeSequence.java + test/javax/swing/Headless/HeadlessSpinnerListModel.java + test/javax/swing/Headless/HeadlessSpinnerNumberModel.java + test/javax/swing/Headless/HeadlessTimer.java Changeset: 687f8a8caca1 Author: sherman Date: 2015-01-22 08:51 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/687f8a8caca1 8069211: (zipfs) ZipFileSystem creates corrupted zip if entry output stream gets closed more than once Summary: to synchronize the write and close methods of the entry output stream Reviewed-by: alanb ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh Changeset: 03a2a9497740 Author: joehw Date: 2019-11-22 00:29 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/03a2a9497740 8233548: Update CUP to v0.11b Reviewed-by: lancea ! THIRD_PARTY_README Changeset: 069ac8d783d8 Author: avstepan Date: 2014-07-09 12:56 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/069ac8d783d8 8047367: move awt automated tests from AWT_Modality to OpenJDK repository - part 2 Reviewed-by: pchelko + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDWFAppModalTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDWFDocModalTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDWFModelessTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDWFNonModalTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDWFTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDialogsAppModalTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDialogsDocModalTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDialogsModelessTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDialogsNonModalTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDialogsTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFDWAppModalTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFDWDocModalTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFDWModelessTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFDWNonModalTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFDWTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDAppModal1Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDAppModal2Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDAppModal3Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDAppModal4Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDDocModal1Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDDocModal2Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDDocModal3Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDDocModal4Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDModeless1Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDModeless2Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDModeless3Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDModeless4Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDNonModal1Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDNonModal2Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDNonModal3Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDNonModal4Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFAppModal1Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFAppModal2Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFAppModal3Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFDocModal1Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFDocModal2Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFDocModal3Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFModeless1Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFModeless2Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFModeless3Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFNonModal1Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFNonModal2Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFNonModal3Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFTest.java + test/java/awt/Modal/ModalitySettingsTest/ModalitySettingsTest.java + test/java/awt/Modal/NullModalityDialogTest/NullModalityDialogTest.java ! test/java/awt/Modal/helpers/TestDialog.java ! test/java/awt/Modal/helpers/TestFrame.java ! test/java/awt/Modal/helpers/TestWindow.java Changeset: 23520a0d3d88 Author: yan Date: 2014-07-04 13:40 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/23520a0d3d88 8048246: Move AWT_DnD/Clipboard/Automated functional tests to OpenJDK Reviewed-by: pchelko Contributed-by: Dmitriy Ermashov + test/java/awt/datatransfer/Clipboard/BasicClipboardTest.java + test/java/awt/datatransfer/Clipboard/GetContentsInterruptedTest.java + test/java/awt/datatransfer/ImageTransfer/ImageTransferTest.java + test/java/awt/datatransfer/Independence/IndependenceAWTTest.java + test/java/awt/datatransfer/Independence/IndependenceSwingTest.java + test/java/awt/datatransfer/SystemFlavorMap/AddFlavorForNativeTest.java + test/java/awt/datatransfer/SystemFlavorMap/AddFlavorTest.java + test/java/awt/datatransfer/SystemFlavorMap/AddNativeForFlavorTest.java + test/java/awt/datatransfer/SystemFlavorMap/AddNativeTest.java + test/java/awt/datatransfer/SystemFlavorMap/GetFlavorsForNewNativeTest.java + test/java/awt/datatransfer/SystemFlavorMap/GetNativesForNewFlavorTest.java + test/java/awt/datatransfer/SystemFlavorMap/InvalidMapArgumentsTest.java + test/java/awt/datatransfer/SystemFlavorMap/ManyFlavorMapTest.java + test/java/awt/datatransfer/SystemFlavorMap/SetDataFlavorsTest.java + test/java/awt/datatransfer/SystemFlavorMap/SetFlavorsForNativeTest.java + test/java/awt/datatransfer/SystemFlavorMap/SetNativesForFlavor.java + test/java/awt/datatransfer/SystemFlavorMap/SetNativesTest.java + test/java/awt/datatransfer/SystemSelection/SystemSelectionAWTTest.java + test/java/awt/datatransfer/SystemSelection/SystemSelectionSwingTest.java Changeset: 0336e02549c5 Author: avstepan Date: 2014-07-21 13:17 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/0336e02549c5 8049617: move awt automated tests from AWT_Modality to OpenJDK repository - part 3 Reviewed-by: pchelko + test/java/awt/Modal/ModalBlockingTests/BlockingDDAppModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDDDocModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDDModelessTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDDNonModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDDSetModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDDTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDDToolkitModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDFAppModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDFSetModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDFTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDFToolkitModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDFWModeless1Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingDFWModeless2Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingDFWNonModal1Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingDFWNonModal2Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingDFWTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDocModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDAppModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDDocModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDModelessTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDNonModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDSetModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDToolkitModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWDocModal1Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWDocModal2Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWDocModal3Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWDocModal4Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWModeless1Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWModeless2Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWModeless3Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWModeless4Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWNonModal1Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWNonModal2Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWNonModal3Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWNonModal4Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsAppModal1Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsAppModal2Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsAppModal3Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsAppModal4Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsAppModal5Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsAppModal6Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsDocModal1Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsDocModal2Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsDocModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsSetModal1Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsSetModal2Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsSetModal3Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsSetModal4Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsSetModal5Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsSetModal6Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsToolkitModal1Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsToolkitModal2Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsToolkitModal3Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsToolkitModal4Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsToolkitModal5Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsToolkitModal6Test.java + test/java/awt/Modal/ModalBlockingTests/UnblockedDialogAppModalTest.java + test/java/awt/Modal/ModalBlockingTests/UnblockedDialogDocModalTest.java + test/java/awt/Modal/ModalBlockingTests/UnblockedDialogModelessTest.java + test/java/awt/Modal/ModalBlockingTests/UnblockedDialogNonModalTest.java + test/java/awt/Modal/ModalBlockingTests/UnblockedDialogSetModalTest.java + test/java/awt/Modal/ModalBlockingTests/UnblockedDialogTest.java + test/java/awt/Modal/ModalBlockingTests/UnblockedDialogToolkitModalTest.java ! test/java/awt/Modal/helpers/TestFrame.java Changeset: e18ce9ba4551 Author: dermashov Date: 2014-07-21 12:29 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/e18ce9ba4551 8049694: Migrate functional AWT_DesktopProperties/Automated tests to OpenJDK Reviewed-by: azvegint, serb + test/java/awt/Toolkit/DesktopProperties/rfe4758438.java + test/java/awt/Toolkit/DesktopProperties/rfe4758438.sh Changeset: 369f33f6166c Author: avstepan Date: 2014-07-29 15:03 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/369f33f6166c 8050885: move awt automated tests from AWT_Modality to OpenJDK repository - part 4 Reviewed-by: pchelko + test/java/awt/Modal/ToFront/DialogToFrontAppModalTest.java + test/java/awt/Modal/ToFront/DialogToFrontDocModalTest.java + test/java/awt/Modal/ToFront/DialogToFrontModalBlockedTest.java + test/java/awt/Modal/ToFront/DialogToFrontModalTest.java + test/java/awt/Modal/ToFront/DialogToFrontModeless1Test.java + test/java/awt/Modal/ToFront/DialogToFrontModelessTest.java + test/java/awt/Modal/ToFront/DialogToFrontNonModalTest.java + test/java/awt/Modal/ToFront/DialogToFrontTKModalTest.java + test/java/awt/Modal/ToFront/FrameToFrontAppModal1Test.java + test/java/awt/Modal/ToFront/FrameToFrontAppModal2Test.java + test/java/awt/Modal/ToFront/FrameToFrontAppModal3Test.java + test/java/awt/Modal/ToFront/FrameToFrontAppModal4Test.java + test/java/awt/Modal/ToFront/FrameToFrontAppModal5Test.java + test/java/awt/Modal/ToFront/FrameToFrontDocModal1Test.java + test/java/awt/Modal/ToFront/FrameToFrontDocModal2Test.java + test/java/awt/Modal/ToFront/FrameToFrontModal1Test.java + test/java/awt/Modal/ToFront/FrameToFrontModal2Test.java + test/java/awt/Modal/ToFront/FrameToFrontModal3Test.java + test/java/awt/Modal/ToFront/FrameToFrontModal4Test.java + test/java/awt/Modal/ToFront/FrameToFrontModal5Test.java + test/java/awt/Modal/ToFront/FrameToFrontModalBlockedTest.java + test/java/awt/Modal/ToFront/FrameToFrontModeless1Test.java + test/java/awt/Modal/ToFront/FrameToFrontModelessTest.java + test/java/awt/Modal/ToFront/FrameToFrontNonModalTest.java + test/java/awt/Modal/ToFront/FrameToFrontTKModal1Test.java + test/java/awt/Modal/ToFront/FrameToFrontTKModal2Test.java + test/java/awt/Modal/ToFront/FrameToFrontTKModal3Test.java + test/java/awt/Modal/ToFront/FrameToFrontTKModal4Test.java + test/java/awt/Modal/ToFront/FrameToFrontTKModal5Test.java ! test/java/awt/Modal/helpers/TestDialog.java ! test/java/awt/Modal/helpers/TestFrame.java ! test/java/awt/Modal/helpers/TestWindow.java Changeset: 1c2fe239ff45 Author: yan Date: 2014-07-21 18:10 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/1c2fe239ff45 8051440: move tests about maximizing undecorated to OpenJDK Reviewed-by: serb + test/java/awt/Frame/MaximizedUndecorated/MaximizedUndecorated.java Changeset: 8cffb2568a6b Author: avstepan Date: 2014-08-05 15:39 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/8cffb2568a6b 8052012: move awt automated tests from AWT_Modality to OpenJDK repository - part 5 Reviewed-by: serb + test/java/awt/Modal/OnTop/OnTopAppModal1Test.java + test/java/awt/Modal/OnTop/OnTopAppModal2Test.java + test/java/awt/Modal/OnTop/OnTopAppModal3Test.java + test/java/awt/Modal/OnTop/OnTopAppModal4Test.java + test/java/awt/Modal/OnTop/OnTopAppModal5Test.java + test/java/awt/Modal/OnTop/OnTopAppModal6Test.java + test/java/awt/Modal/OnTop/OnTopDDFTest.java + test/java/awt/Modal/OnTop/OnTopDocModal1Test.java + test/java/awt/Modal/OnTop/OnTopDocModal2Test.java + test/java/awt/Modal/OnTop/OnTopDocModal3Test.java + test/java/awt/Modal/OnTop/OnTopDocModal4Test.java + test/java/awt/Modal/OnTop/OnTopDocModal5Test.java + test/java/awt/Modal/OnTop/OnTopDocModal6Test.java + test/java/awt/Modal/OnTop/OnTopFDFTest.java + test/java/awt/Modal/OnTop/OnTopModal1Test.java + test/java/awt/Modal/OnTop/OnTopModal2Test.java + test/java/awt/Modal/OnTop/OnTopModal3Test.java + test/java/awt/Modal/OnTop/OnTopModal4Test.java + test/java/awt/Modal/OnTop/OnTopModal5Test.java + test/java/awt/Modal/OnTop/OnTopModal6Test.java + test/java/awt/Modal/OnTop/OnTopModeless1Test.java + test/java/awt/Modal/OnTop/OnTopModeless2Test.java + test/java/awt/Modal/OnTop/OnTopModeless3Test.java + test/java/awt/Modal/OnTop/OnTopModeless4Test.java + test/java/awt/Modal/OnTop/OnTopModeless5Test.java + test/java/awt/Modal/OnTop/OnTopModeless6Test.java + test/java/awt/Modal/OnTop/OnTopTKModal1Test.java + test/java/awt/Modal/OnTop/OnTopTKModal2Test.java + test/java/awt/Modal/OnTop/OnTopTKModal3Test.java + test/java/awt/Modal/OnTop/OnTopTKModal4Test.java + test/java/awt/Modal/OnTop/OnTopTKModal5Test.java + test/java/awt/Modal/OnTop/OnTopTKModal6Test.java Changeset: 88dba8ecce55 Author: dermashov Date: 2014-07-30 14:29 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/88dba8ecce55 8052408: Move AWT_BAT functional tests to OpenJDK (3 of 3) Reviewed-by: alexsch + test/javax/swing/reliability/GUIUndFrame.java + test/javax/swing/reliability/GUIZoomFrame.java + test/javax/swing/reliability/Task.java + test/javax/swing/reliability/TaskUndJFrameProperties.java + test/javax/swing/reliability/TaskZoomJFrameChangeState.java + test/javax/swing/reliability/TaskZoomJFrameRepaint.java Changeset: f2d68ba3f3d3 Author: yan Date: 2014-08-12 18:26 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/f2d68ba3f3d3 8053657: [TEST_BUG] move some 5 tests related to undecorated Frame/JFrame to JDK Reviewed-by: serb + test/java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java + test/java/awt/Frame/MiscUndecorated/ActiveSwingWindowTest.java + test/java/awt/Frame/MiscUndecorated/FrameCloseTest.java + test/java/awt/Frame/MiscUndecorated/RepaintTest.java + test/java/awt/Frame/MiscUndecorated/UndecoratedInitiallyIconified.java - test/java/awt/Mixing/AWT_Mixing/Util.java Changeset: 56bbba50b9b8 Author: avstepan Date: 2014-11-19 14:12 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/56bbba50b9b8 8054143: move awt automated tests from AWT_Modality to OpenJDK repository - part 6 Reviewed-by: pchelko + test/java/awt/Modal/ToBack/ToBackAppModal1Test.java + test/java/awt/Modal/ToBack/ToBackAppModal2Test.java + test/java/awt/Modal/ToBack/ToBackAppModal3Test.java + test/java/awt/Modal/ToBack/ToBackAppModal4Test.java + test/java/awt/Modal/ToBack/ToBackAppModal5Test.java + test/java/awt/Modal/ToBack/ToBackAppModal6Test.java + test/java/awt/Modal/ToBack/ToBackDDFTest.java + test/java/awt/Modal/ToBack/ToBackDocModal1Test.java + test/java/awt/Modal/ToBack/ToBackDocModal2Test.java + test/java/awt/Modal/ToBack/ToBackDocModal3Test.java + test/java/awt/Modal/ToBack/ToBackDocModal4Test.java + test/java/awt/Modal/ToBack/ToBackDocModal5Test.java + test/java/awt/Modal/ToBack/ToBackDocModal6Test.java + test/java/awt/Modal/ToBack/ToBackFDFTest.java + test/java/awt/Modal/ToBack/ToBackModal1Test.java + test/java/awt/Modal/ToBack/ToBackModal2Test.java + test/java/awt/Modal/ToBack/ToBackModal3Test.java + test/java/awt/Modal/ToBack/ToBackModal4Test.java + test/java/awt/Modal/ToBack/ToBackModal5Test.java + test/java/awt/Modal/ToBack/ToBackModal6Test.java + test/java/awt/Modal/ToBack/ToBackModeless1Test.java + test/java/awt/Modal/ToBack/ToBackModeless2Test.java + test/java/awt/Modal/ToBack/ToBackModeless3Test.java + test/java/awt/Modal/ToBack/ToBackModeless4Test.java + test/java/awt/Modal/ToBack/ToBackModeless5Test.java + test/java/awt/Modal/ToBack/ToBackModeless6Test.java + test/java/awt/Modal/ToBack/ToBackNonModal1Test.java + test/java/awt/Modal/ToBack/ToBackNonModal2Test.java + test/java/awt/Modal/ToBack/ToBackNonModal3Test.java + test/java/awt/Modal/ToBack/ToBackNonModal4Test.java + test/java/awt/Modal/ToBack/ToBackNonModal5Test.java + test/java/awt/Modal/ToBack/ToBackNonModal6Test.java + test/java/awt/Modal/ToBack/ToBackTKModal1Test.java + test/java/awt/Modal/ToBack/ToBackTKModal2Test.java + test/java/awt/Modal/ToBack/ToBackTKModal3Test.java + test/java/awt/Modal/ToBack/ToBackTKModal4Test.java + test/java/awt/Modal/ToBack/ToBackTKModal5Test.java + test/java/awt/Modal/ToBack/ToBackTKModal6Test.java Changeset: 6677c8b3ac77 Author: avstepan Date: 2014-12-30 17:26 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/6677c8b3ac77 8054358: move awt automated tests from AWT_Modality to OpenJDK repository - part 7 Reviewed-by: pchelko + test/java/awt/Modal/MultipleDialogs/MultipleDialogs1Test.java + test/java/awt/Modal/MultipleDialogs/MultipleDialogs2Test.java + test/java/awt/Modal/MultipleDialogs/MultipleDialogs3Test.java + test/java/awt/Modal/MultipleDialogs/MultipleDialogs4Test.java + test/java/awt/Modal/MultipleDialogs/MultipleDialogs5Test.java Changeset: d0fea9e605f0 Author: avstepan Date: 2014-11-18 17:10 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/d0fea9e605f0 8054359: move awt automated tests from AWT_Modality to OpenJDK repository - part 8 Summary: Some new tests to check FileDialog modality behavior Reviewed-by: alexsch, pchelko + test/java/awt/Modal/FileDialog/FileDialogAppModal1Test.java + test/java/awt/Modal/FileDialog/FileDialogAppModal2Test.java + test/java/awt/Modal/FileDialog/FileDialogAppModal3Test.java + test/java/awt/Modal/FileDialog/FileDialogAppModal4Test.java + test/java/awt/Modal/FileDialog/FileDialogAppModal5Test.java + test/java/awt/Modal/FileDialog/FileDialogAppModal6Test.java + test/java/awt/Modal/FileDialog/FileDialogDWDTest.java + test/java/awt/Modal/FileDialog/FileDialogDocModal1Test.java + test/java/awt/Modal/FileDialog/FileDialogDocModal2Test.java + test/java/awt/Modal/FileDialog/FileDialogDocModal3Test.java + test/java/awt/Modal/FileDialog/FileDialogDocModal4Test.java + test/java/awt/Modal/FileDialog/FileDialogDocModal5Test.java + test/java/awt/Modal/FileDialog/FileDialogDocModal6Test.java + test/java/awt/Modal/FileDialog/FileDialogDocModal7Test.java + test/java/awt/Modal/FileDialog/FileDialogFWDTest.java + test/java/awt/Modal/FileDialog/FileDialogModal1Test.java + test/java/awt/Modal/FileDialog/FileDialogModal2Test.java + test/java/awt/Modal/FileDialog/FileDialogModal3Test.java + test/java/awt/Modal/FileDialog/FileDialogModal4Test.java + test/java/awt/Modal/FileDialog/FileDialogModal5Test.java + test/java/awt/Modal/FileDialog/FileDialogModal6Test.java + test/java/awt/Modal/FileDialog/FileDialogModalityTest.java + test/java/awt/Modal/FileDialog/FileDialogNonModal1Test.java + test/java/awt/Modal/FileDialog/FileDialogNonModal2Test.java + test/java/awt/Modal/FileDialog/FileDialogNonModal3Test.java + test/java/awt/Modal/FileDialog/FileDialogNonModal4Test.java + test/java/awt/Modal/FileDialog/FileDialogNonModal5Test.java + test/java/awt/Modal/FileDialog/FileDialogNonModal6Test.java + test/java/awt/Modal/FileDialog/FileDialogNonModal7Test.java + test/java/awt/Modal/FileDialog/FileDialogTKModal1Test.java + test/java/awt/Modal/FileDialog/FileDialogTKModal2Test.java + test/java/awt/Modal/FileDialog/FileDialogTKModal3Test.java + test/java/awt/Modal/FileDialog/FileDialogTKModal4Test.java + test/java/awt/Modal/FileDialog/FileDialogTKModal5Test.java + test/java/awt/Modal/FileDialog/FileDialogTKModal6Test.java + test/java/awt/Modal/FileDialog/FileDialogTKModal7Test.java Changeset: 893bc7a633d8 Author: dermashov Date: 2014-08-26 15:04 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/893bc7a633d8 8055360: Move the rest part of AWT ShapedAndTranslucent tests to OpenJDK Reviewed-by: alexsch + test/javax/swing/JWindow/ShapedAndTranslucentWindows/Common.java + test/javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucent.java + test/javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucentCanvas.java + test/javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucentGradient.java + test/javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucentSwing.java + test/javax/swing/JWindow/ShapedAndTranslucentWindows/SetShapeAndClickSwing.java + test/javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedPerPixelTranslucentGradient.java + test/javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedTranslucentPerPixelTranslucentGradient.java + test/javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentJComboBox.java + test/javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java + test/javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentWindowClickSwing.java Changeset: 93f4b1706b7e Author: yan Date: 2014-08-29 14:27 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/93f4b1706b7e 8055664: move 14 tests about setLocationRelativeTo to jdk Reviewed-by: alexsch, azvegint + test/java/awt/Window/setLocRelativeTo/SetLocationRelativeToTest.java Changeset: 985f5f33d7ab Author: avstepan Date: 2014-11-18 16:32 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/985f5f33d7ab 8055836: move awt tests from AWT_Modality to OpenJDK repository - part 9 8057694: move awt tests from AWT_Modality to OpenJDK repository - part 10 Summary: Some modality tests for Print dialog were added Reviewed-by: pchelko + test/java/awt/Modal/PrintDialogsTest/PrintDialogsTest.html + test/java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java + test/java/awt/Modal/PrintDialogsTest/Test.java Changeset: 425618a5301b Author: yan Date: 2015-04-07 17:34 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/425618a5301b 8076315: move 4 manual functional swing tests to regression suite Reviewed-by: alexsch, serb + test/javax/swing/JColorChooser/Test4319113.html + test/javax/swing/JColorChooser/Test4319113.java + test/javax/swing/JOptionPane/4174551/bug4174551.html + test/javax/swing/JOptionPane/4174551/bug4174551.java + test/javax/swing/JTabbedPane/4666224/bug4666224.html + test/javax/swing/JTabbedPane/4666224/bug4666224.java + test/javax/swing/JToolTip/4644444/bug4644444.html + test/javax/swing/JToolTip/4644444/bug4644444.java Changeset: 18a3b77136f6 Author: pchelko Date: 2014-06-16 17:13 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/18a3b77136f6 8046221: [TEST_BUG] Cleanup datatransfer tests Reviewed-by: anthony, alexsch - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/AbsoluteComponentCenterCalculator.java - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/DataFlavorSearcher.java - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/InterprocessMessages.java - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.html - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.java - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MyTransferable.java - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/NextFramePositionCalculator.java - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/SourcePanel.java - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/TargetPanel.java + test/java/awt/datatransfer/DataFlavor/DataFlavorCloneTest/DataFlavorCloneTest.java + test/java/awt/datatransfer/DataFlavor/DataFlavorEqualsNullTest.java + test/java/awt/datatransfer/DataFlavor/DataFlavorEqualsTest.java + test/java/awt/datatransfer/DataFlavor/DataFlavorFileListTest.java + test/java/awt/datatransfer/DataFlavor/DataFlavorSerializedTest.java + test/java/awt/datatransfer/DataFlavor/DefaultMatchTest.java + test/java/awt/datatransfer/DataFlavor/EqualHashCodeTest.java + test/java/awt/datatransfer/DataFlavor/ExternalizeTest.java + test/java/awt/datatransfer/DataFlavor/GetReaderForTextIAEForStringSelectionTest.java + test/java/awt/datatransfer/DataFlavor/GetReaderForTextNPETest.java + test/java/awt/datatransfer/DataFlavor/MimeTypeSerializationTest.java + test/java/awt/datatransfer/DataFlavor/NoClassParameterTest.java + test/java/awt/datatransfer/DataFlavor/NormalizeMimeTypeParameter.java + test/java/awt/datatransfer/DataFlavor/NullDataFlavorTest.java + test/java/awt/datatransfer/DataFlavor/ReaderForUnicodeText.java + test/java/awt/datatransfer/DataFlavor/SelectBestFlavorNPETest.java + test/java/awt/datatransfer/DataFlavor/SelectBestTextFlavorBadArrayTest.java + test/java/awt/datatransfer/DataFlavor/ToStringNullPointerTest.java - test/java/awt/datatransfer/DuplicatedNativesTest/DuplicatedNativesTest.java - test/java/awt/datatransfer/MappingGenerationTest/MappingGenerationTest.java + test/java/awt/datatransfer/MissedHtmlAndRtfBug/AbsoluteComponentCenterCalculator.java + test/java/awt/datatransfer/MissedHtmlAndRtfBug/DataFlavorSearcher.java + test/java/awt/datatransfer/MissedHtmlAndRtfBug/InterprocessMessages.java + test/java/awt/datatransfer/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.html + test/java/awt/datatransfer/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.java + test/java/awt/datatransfer/MissedHtmlAndRtfBug/MyTransferable.java + test/java/awt/datatransfer/MissedHtmlAndRtfBug/NextFramePositionCalculator.java + test/java/awt/datatransfer/MissedHtmlAndRtfBug/SourcePanel.java + test/java/awt/datatransfer/MissedHtmlAndRtfBug/TargetPanel.java + test/java/awt/datatransfer/SystemFlavorMap/DuplicateMappingTest.java + test/java/awt/datatransfer/SystemFlavorMap/DuplicatedNativesTest.java + test/java/awt/datatransfer/SystemFlavorMap/GetNativesForFlavorTest.java + test/java/awt/datatransfer/SystemFlavorMap/MappingGenerationTest.java + test/java/awt/datatransfer/SystemFlavorMap/SetNativesForFlavorTest.java Changeset: 2239168b30f5 Author: serb Date: 2020-08-18 00:06 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/2239168b30f5 8022535: [TEST BUG] javax/swing/text/html/parser/Test8017492.java fails Reviewed-by: prr, pbansal ! test/javax/swing/text/html/parser/Test8017492.java Changeset: a02808994648 Author: yan Date: 2014-12-05 14:55 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/a02808994648 8063104: Change open awt regression tests to avoid sun.awt.SunToolkit.realSync, part 2 Reviewed-by: serb, alexsch + test/java/awt/Choice/DragMouseOutAndRelease/DragMouseOutAndRelease.java + test/java/awt/Choice/GetSizeTest/GetSizeTest.java + test/java/awt/Choice/GrabLockTest/GrabLockTest.java + test/java/awt/Choice/PopupPosTest/PopupPosTest.html + test/java/awt/Choice/PopupPosTest/PopupPosTest.java + test/java/awt/Choice/ResizeAutoClosesChoice/ResizeAutoClosesChoice.java + test/java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.html + test/java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.java + test/java/awt/Choice/UnfocusableCB_ERR/UnfocusableCB_ERR.java ! test/java/awt/Component/7097771/bug7097771.java ! test/java/awt/Component/F10TopToplevel/F10TopToplevel.java + test/java/awt/Component/NativeInLightShow/NativeInLightShow.java + test/java/awt/FileDialog/ISCthrownByFileListTest/ISCthrownByFileListTest.java + test/java/awt/Focus/6378278/InputVerifierTest.java + test/java/awt/Focus/6382144/EndlessLoopTest.java + test/java/awt/Focus/6401036/InputVerifierTest2.java + test/java/awt/Focus/ChildWindowFocusTest/ChildWindowFocusTest.html + test/java/awt/Focus/ChildWindowFocusTest/ChildWindowFocusTest.java + test/java/awt/Focus/DisposedWindow/DisposeDialogNotActivateOwnerTest/DisposeDialogNotActivateOwnerTest.html + test/java/awt/Focus/DisposedWindow/DisposeDialogNotActivateOwnerTest/DisposeDialogNotActivateOwnerTest.java ! test/java/awt/Focus/FocusEmbeddedFrameTest/FocusEmbeddedFrameTest.java + test/java/awt/Focus/FocusSubRequestTest/FocusSubRequestTest.html + test/java/awt/Focus/FocusSubRequestTest/FocusSubRequestTest.java ! test/java/awt/Focus/KeyEventForBadFocusOwnerTest/KeyEventForBadFocusOwnerTest.java + test/java/awt/Focus/ModalDialogInitialFocusTest/ModalDialogInitialFocusTest.html + test/java/awt/Focus/ModalDialogInitialFocusTest/ModalDialogInitialFocusTest.java + test/java/awt/Focus/MouseClickRequestFocusRaceTest/MouseClickRequestFocusRaceTest.html + test/java/awt/Focus/MouseClickRequestFocusRaceTest/MouseClickRequestFocusRaceTest.java ! test/java/awt/Focus/SimpleWindowActivationTest/SimpleWindowActivationTest.java + test/java/awt/Frame/GetBoundsResizeTest/GetBoundsResizeTest.java ! test/java/awt/FullScreen/8013581/bug8013581.java ! test/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java + test/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeForModalDialogTest/ConsumeForModalDialogTest.html + test/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeForModalDialogTest/ConsumeForModalDialogTest.java + test/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest.html + test/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest.java + test/java/awt/KeyboardFocusmanager/TypeAhead/EnqueueWithDialogButtonTest/EnqueueWithDialogButtonTest.java + test/java/awt/KeyboardFocusmanager/TypeAhead/EnqueueWithDialogTest/EnqueueWithDialogTest.java + test/java/awt/KeyboardFocusmanager/TypeAhead/FreezeTest/FreezeTest.java ! test/java/awt/List/ActionAfterRemove/ActionAfterRemove.java ! test/java/awt/List/EmptyListEventTest/EmptyListEventTest.java + test/java/awt/List/KeyEventsTest/KeyEventsTest.html + test/java/awt/List/KeyEventsTest/KeyEventsTest.java ! test/java/awt/List/NofocusListDblClickTest/NofocusListDblClickTest.java ! test/java/awt/List/ScrollOutside/ScrollOut.java ! test/java/awt/List/SetBackgroundTest/SetBackgroundTest.java ! test/java/awt/MenuBar/8007006/bug8007006.java ! test/java/awt/MenuBar/MenuBarSetFont/MenuBarSetFont.java ! test/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java ! test/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java ! test/java/awt/Modal/ModalDialogOrderingTest/ModalDialogOrderingTest.java ! test/java/awt/Modal/ModalInternalFrameTest/ModalInternalFrameTest.java ! test/java/awt/Mouse/EnterExitEvents/DragWindowOutOfFrameTest.java ! test/java/awt/Mouse/EnterExitEvents/DragWindowTest.java ! test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java ! test/java/awt/Mouse/MouseComboBoxTest/MouseComboBoxTest.java ! test/java/awt/Multiscreen/MouseEventTest/MouseEventTest.java ! test/java/awt/Paint/PaintNativeOnUpdate.java ! test/java/awt/Robot/CtorTest/CtorTest.java + test/java/awt/TextArea/ScrollbarIntersectionTest/ScrollbarIntersectionTest.java ! test/java/awt/TextField/SelectionInvisibleTest/SelectionInvisibleTest.java + test/java/awt/Toolkit/RealSync/Test.java ! test/java/awt/Window/AlwaysOnTop/TestAlwaysOnTopBeforeShow.java ! test/java/awt/Window/BackgroundIsNotUpdated/BackgroundIsNotUpdated.java ! test/java/awt/Window/TranslucentJAppletTest/TranslucentJAppletTest.java ! test/java/awt/dnd/ImageTransferTest/ImageTransferTest.java ! test/java/awt/dnd/MissingDragExitEventTest/MissingDragExitEventTest.java ! test/java/awt/event/InputEvent/EventWhenTest/EventWhenTest.java ! test/java/awt/event/KeyEvent/8020209/bug8020209.java ! test/java/awt/event/KeyEvent/DeadKey/DeadKeyMacOSXInputText.java ! test/java/awt/event/KeyEvent/DeadKey/DeadKeySystemAssertionDialog.java ! test/java/awt/event/KeyEvent/DeadKey/deadKeyMacOSX.java ! test/java/awt/event/KeyEvent/ExtendedKeyCode/ExtendedKeyCodeTest.java ! test/java/awt/event/KeyEvent/KeyChar/KeyCharTest.java + test/java/awt/event/MouseEvent/ClickDuringKeypress/ClickDuringKeypress.java ! test/java/awt/event/MouseWheelEvent/DisabledComponent/DisabledComponent.java ! test/java/awt/grab/EmbeddedFrameTest1/EmbeddedFrameTest1.java + test/java/awt/grab/MenuDragEvents/MenuDragEvents.html + test/java/awt/grab/MenuDragEvents/MenuDragEvents.java ! test/java/awt/regtesthelpers/Util.java + test/java/awt/regtesthelpers/UtilInternal.java ! test/javax/swing/JLabel/6596966/bug6596966.java ! test/javax/swing/regtesthelpers/Util.java ! test/sun/awt/dnd/8024061/bug8024061.java Changeset: fce2514e40f1 Author: yan Date: 2014-06-09 14:59 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/fce2514e40f1 8044765: Move functional tests AWT_SystemTray/Automated to openjdk repository Reviewed-by: pchelko Contributed-by: Dmitriy Ermashov + test/java/awt/TrayIcon/ActionCommand/ActionCommand.java + test/java/awt/TrayIcon/ActionEventMask/ActionEventMask.java + test/java/awt/TrayIcon/GetTrayIconsTest/GetTrayIcons.java + test/java/awt/TrayIcon/InterJVMTest/InterJVM.java + test/java/awt/TrayIcon/ModalityTest/ModalityTest.java + test/java/awt/TrayIcon/MouseEventMask/MouseEventMaskTest.java + test/java/awt/TrayIcon/MouseMovedTest/MouseMovedTest.java + test/java/awt/TrayIcon/PropertyChangeListenerTest.java + test/java/awt/TrayIcon/SecurityCheck/FunctionalityCheck/FunctionalityCheck.java + test/java/awt/TrayIcon/SecurityCheck/FunctionalityCheck/tray.policy + test/java/awt/TrayIcon/SecurityCheck/NoPermissionTest/NoPermissionTest.java + test/java/awt/TrayIcon/SecurityCheck/PermissionTest/PermissionTest.java + test/java/awt/TrayIcon/SecurityCheck/PermissionTest/tray.policy + test/java/awt/TrayIcon/SystemTrayIconHelper.java + test/java/awt/TrayIcon/SystemTrayInstance/SystemTrayInstanceTest.java + test/java/awt/TrayIcon/TrayIconAddTest/TrayIconAddTest.java + test/java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java + test/java/awt/TrayIcon/TrayIconEvents/TrayIconEventsTest.java + test/java/awt/TrayIcon/TrayIconMethodsTest/TrayIconMethodsTest.java + test/java/awt/TrayIcon/TrayIconMouseTest/TrayIconMouseTest.java + test/java/awt/TrayIcon/TrayIconPopup/TrayIconPopupTest.java + test/java/awt/TrayIcon/TrayIconRemoveTest/TrayIconRemoveTest.java + test/java/awt/TrayIcon/TrayIconSizeTest/TrayIconSizeTest.java Changeset: 21dd9256a2e9 Author: serb Date: 2014-12-25 22:48 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/21dd9256a2e9 8068275: Some tests failed after JDK-8063104 Reviewed-by: azvegint, yan ! test/java/awt/regtesthelpers/Util.java Changeset: 5efa85c88a30 Author: alexsch Date: 2014-12-15 19:21 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/5efa85c88a30 8067441: Some tests fails with error: cannot find symbol getSystemMnemonicKeyCodes() Reviewed-by: serb, azvegint ! test/javax/swing/regtesthelpers/Util.java Changeset: 7f0d0fd0f054 Author: yan Date: 2015-03-18 10:30 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/7f0d0fd0f054 8074807: Fix some tests unnecessary using internal API Reviewed-by: azvegint, alexsch + test/java/awt/Focus/ModalExcludedWindowClickTest/ModalExcludedWindowClickTest.html + test/java/awt/Focus/ModalExcludedWindowClickTest/ModalExcludedWindowClickTest.java + test/java/awt/Focus/NonFocusableBlockedOwnerTest/NonFocusableBlockedOwnerTest.html + test/java/awt/Focus/NonFocusableBlockedOwnerTest/NonFocusableBlockedOwnerTest.java + test/java/awt/Focus/WindowUpdateFocusabilityTest/WindowUpdateFocusabilityTest.html + test/java/awt/Focus/WindowUpdateFocusabilityTest/WindowUpdateFocusabilityTest.java ! test/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.java + test/java/awt/Window/AlwaysOnTop/AutoTestOnTop.java + test/java/awt/event/ComponentEvent/MovedResizedTardyEventTest/MovedResizedTardyEventTest.html + test/java/awt/event/ComponentEvent/MovedResizedTardyEventTest/MovedResizedTardyEventTest.java ! test/java/awt/event/KeyEvent/AltCharAcceleratorTest/AltCharAcceleratorTest.java ! test/java/awt/keyboard/EqualKeyCode/EqualKeyCode.java ! test/javax/swing/ToolTipManager/7123767/bug7123767.java Changeset: 2b1f2810e054 Author: yan Date: 2014-11-10 16:23 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/2b1f2810e054 8063102: Change open awt regression tests to avoid sun.awt.SunToolkit.realSync, part 1 Reviewed-by: pchelko, serb ! test/com/sun/awt/Translucency/WindowOpacity.java ! test/java/awt/Component/NoUpdateUponShow/NoUpdateUponShow.java ! test/java/awt/Component/PaintAll/PaintAll.java ! test/java/awt/Focus/ModalBlockedStealsFocusTest/ModalBlockedStealsFocusTest.java ! test/java/awt/Focus/WindowInitialFocusTest/WindowInitialFocusTest.java ! test/java/awt/Frame/ExceptionOnSetExtendedStateTest/ExceptionOnSetExtendedStateTest.java ! test/java/awt/Frame/FrameSize/TestFrameSize.java ! test/java/awt/Frame/MaximizedByPlatform/MaximizedByPlatform.java ! test/java/awt/Frame/MaximizedToMaximized/MaximizedToMaximized.java ! test/java/awt/Frame/SlideNotResizableTest/SlideNotResizableTest.java ! test/java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java ! test/java/awt/GraphicsDevice/IncorrectDisplayModeExitFullscreen.java ! test/java/awt/GridBagLayout/GridBagLayoutIpadXYTest/GridBagLayoutIpadXYTest.java ! test/java/awt/List/ListPeer/R2303044ListSelection.java ! test/java/awt/List/SingleModeDeselect/SingleModeDeselect.java ! test/java/awt/Paint/ExposeOnEDT.java ! test/java/awt/ScrollPane/ScrollPanePreferredSize/ScrollPanePreferredSize.java ! test/java/awt/TextArea/DisposeTest/TestDispose.java ! test/java/awt/TextArea/TextAreaCaretVisibilityTest/bug7129742.java ! test/java/awt/TextArea/TextAreaTwicePack/TextAreaTwicePack.java ! test/java/awt/TextField/DisposeTest/TestDispose.java ! test/java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java ! test/java/awt/Window/8027025/Test8027025.java ! test/java/awt/Window/AlwaysOnTop/AlwaysOnTopFieldTest.java ! test/java/awt/Window/OwnedWindowsSerialization/OwnedWindowsSerialization.java ! test/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest.java Changeset: aef03a4e95d7 Author: yan Date: 2014-11-10 16:37 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/aef03a4e95d7 8063106: Change open swing regression tests to avoid sun.awt.SunToolkit.realSync, part 1 Reviewed-by: pchelko, serb ! test/com/sun/java/swing/plaf/windows/8016551/bug8016551.java + test/java/awt/Component/CompEventOnHiddenComponent/CompEventOnHiddenComponent.java + test/java/awt/Window/GetWindowsTest/GetWindowsTest.java + test/java/awt/Window/HandleWindowDestroyTest/HandleWindowDestroyTest.html + test/java/awt/Window/HandleWindowDestroyTest/HandleWindowDestroyTest.java + test/java/awt/event/ComponentEvent/MovedResizedTwiceTest/MovedResizedTwiceTest.java ! test/javax/swing/JButton/JButtonPaintNPE/JButtonPaintNPE.java + test/javax/swing/JComboBox/6406264/bug6406264.java ! test/javax/swing/JComboBox/8015300/Test8015300.java ! test/javax/swing/JComboBox/ShowPopupAfterHidePopupTest/ShowPopupAfterHidePopupTest.java ! test/javax/swing/JComponent/6989617/bug6989617.java ! test/javax/swing/JEditorPane/4492274/bug4492274.java ! test/javax/swing/JInternalFrame/4251301/bug4251301.java ! test/javax/swing/JInternalFrame/6647340/bug6647340.java ! test/javax/swing/JInternalFrame/6725409/bug6725409.java ! test/javax/swing/JLayer/6824395/bug6824395.java + test/javax/swing/JPopupMenu/6583251/bug6583251.java ! test/javax/swing/JPopupMenu/6691503/bug6691503.java ! test/javax/swing/JPopupMenu/6694823/bug6694823.java ! test/javax/swing/JScrollBar/4865918/bug4865918.java + test/javax/swing/JScrollPane/6274267/bug6274267.java ! test/javax/swing/JSpinner/8008657/bug8008657.java ! test/javax/swing/JSplitPane/4816114/bug4816114.java ! test/javax/swing/JTabbedPane/7024235/Test7024235.java ! test/javax/swing/JTabbedPane/7170310/bug7170310.java ! test/javax/swing/JTable/8032874/bug8032874.java ! test/javax/swing/JTextArea/7049024/bug7049024.java + test/javax/swing/JToolBar/4529206/bug4529206.java ! test/javax/swing/JViewport/7107099/bug7107099.java + test/javax/swing/Popup/6514582/bug6514582.java ! test/javax/swing/RepaintManager/IconifyTest/IconifyTest.java ! test/javax/swing/Security/6657138/ComponentTest.java ! test/javax/swing/SwingTest.java ! test/javax/swing/text/Utilities/bug7045593.java ! test/javax/swing/text/View/8048110/bug8048110.java ! test/javax/swing/text/html/7189299/bug7189299.java ! test/javax/swing/text/html/HTMLDocument/8058120/bug8058120.java ! test/javax/swing/text/html/HTMLEditorKit/4242228/bug4242228.java ! test/javax/swing/text/html/parser/Parser/7165725/bug7165725.java Changeset: a8f6ae69c42c Author: kshefov Date: 2014-11-07 14:20 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/a8f6ae69c42c 8058805: [TEST_BUG]Test java/awt/TrayIcon/SecurityCheck/NoPermissionTest/NoPermissionTest.java fails Reviewed-by: yan, alexsch Contributed-by: pooja.chopra at oracle.com + test/java/awt/TrayIcon/SecurityCheck/NoPermissionTest/tray.policy Changeset: e12acc73cbc2 Author: aivanov Date: 2015-07-09 15:26 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/e12acc73cbc2 8130772: Util.hitMnemonics does not work: getSystemMnemonicKeyCodes() returns ALT_MASK rather than VK_ALT Reviewed-by: serb, alexsch ! test/javax/swing/regtesthelpers/Util.java Changeset: b3f891cf668e Author: weijun Date: 2019-05-07 10:21 +0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/b3f891cf668e 8219013: Update Apache Santuario (XML Signature) to version 2.1.3 Reviewed-by: mullan ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureDSA.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureECDSA.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315Excl.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/KeyInfo.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyValue.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/keyvalues/ECKeyValue.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509SKI.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolver.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/ECKeyValueResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/RSAKeyValueResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/CertsInFilesystemDirectoryResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/config.xml ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Manifest.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Reference.java + src/share/classes/com/sun/org/apache/xml/internal/security/signature/VerifiedReference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignature.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformBase64Decode.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXSLT.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPathFilterCHGPContainer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/Constants.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/Signature11ElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/XMLUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverDirectHTTP.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheOctetStreamData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14NMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCryptoBinary.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMDigestMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMEnvelopedTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMExcC14NMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMHMACSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfoFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyName.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperty.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMStructure.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMUtils.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509Data.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509IssuerSerial.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLObject.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignatureFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXSLTTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java Changeset: 401773a77147 Author: ebaron Date: 2020-11-25 12:31 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/401773a77147 8229868: Update Apache Santuario TPRM version Reviewed-by: phh ! THIRD_PARTY_README Changeset: 0c39a12473c9 Author: alvdavi Date: 2020-11-26 10:43 -0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/0c39a12473c9 8249846: Change of behavior after JDK-8237117: Better ForkJoinPool behavior Reviewed-by: mbalao ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! test/java/util/concurrent/forkjoin/AccessControlContext.java Changeset: 93c777477e2c Author: ssadetsky Date: 2015-12-01 19:07 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/93c777477e2c 8068228: Test closed/java/awt/Mouse/MaximizedFrameTest/MaximizedFrameTest fails with GTKLookAndFeel Reviewed-by: ssadetsky, arapte - test/java/awt/Mouse/MaximizedFrameTest/MaximizedFrameTest.html ! test/java/awt/Mouse/MaximizedFrameTest/MaximizedFrameTest.java Changeset: c7c0c3c9f33c Author: yan Date: 2014-11-21 16:11 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/c7c0c3c9f33c 8063107: Change open swing regression tests to avoid sun.awt.SunToolkit.realSync, part 2 8064573: [TEST_BUG] javax/swing/text/AbstractDocument/6968363/Test6968363.java is asocial pressing VK_LEFT and not releasing 8064575: [TEST_BUG] javax/swing/JEditorPane/6917744/bug6917744.java 100 times press keys and never releases 8064809: [TEST_BUG] javax/swing/JComboBox/4199622/bug4199622.java contains a lot of keyPress and not a single keyRelease Reviewed-by: alexsch, pchelko ! test/javax/swing/AbstractButton/6711682/bug6711682.java + test/javax/swing/JButton/4368790/bug4368790.java ! test/javax/swing/JColorChooser/Test6541987.java ! test/javax/swing/JColorChooser/Test6827032.java ! test/javax/swing/JColorChooser/Test7194184.java ! test/javax/swing/JComboBox/4199622/bug4199622.java + test/javax/swing/JComboBox/4515752/DefaultButtonTest.java ! test/javax/swing/JComboBox/4743225/bug4743225.java ! test/javax/swing/JComboBox/6236162/bug6236162.java + test/javax/swing/JComboBox/6559152/bug6559152.java ! test/javax/swing/JComboBox/6607130/bug6607130.java ! test/javax/swing/JComboBox/8032878/bug8032878.java ! test/javax/swing/JComboBox/8057893/bug8057893.java ! test/javax/swing/JComponent/6683775/bug6683775.java ! test/javax/swing/JComponent/7154030/bug7154030.java ! test/javax/swing/JEditorPane/6917744/bug6917744.java ! test/javax/swing/JFileChooser/4524490/bug4524490.java ! test/javax/swing/JFileChooser/7199708/bug7199708.java ! test/javax/swing/JFileChooser/8002077/bug8002077.java ! test/javax/swing/JFileChooser/8021253/bug8021253.java ! test/javax/swing/JFrame/4962534/bug4962534.java ! test/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java ! test/javax/swing/JInternalFrame/5066752/bug5066752.java ! test/javax/swing/JInternalFrame/8020708/bug8020708.java ! test/javax/swing/JInternalFrame/InternalFrameIsNotCollectedTest.java ! test/javax/swing/JList/6462008/bug6462008.java + test/javax/swing/JList/6510999/bug6510999.java + test/javax/swing/JMenu/4417601/bug4417601.java ! test/javax/swing/JMenu/4515762/bug4515762.java ! test/javax/swing/JMenu/4692443/bug4692443.java + test/javax/swing/JMenu/6359669/bug6359669.java + test/javax/swing/JMenu/6470128/bug6470128.java + test/javax/swing/JMenu/6538132/bug6538132.java ! test/javax/swing/JMenuBar/4750590/bug4750590.java ! test/javax/swing/JMenuItem/4171437/bug4171437.java ! test/javax/swing/JMenuItem/4654927/bug4654927.java ! test/javax/swing/JMenuItem/6209975/bug6209975.java + test/javax/swing/JMenuItem/6249972/bug6249972.java ! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java + test/javax/swing/JOptionPane/6428694/bug6428694.java ! test/javax/swing/JOptionPane/7138665/bug7138665.java ! test/javax/swing/JPopupMenu/4458079/bug4458079.java + test/javax/swing/JPopupMenu/4634626/bug4634626.html + test/javax/swing/JPopupMenu/4634626/bug4634626.java ! test/javax/swing/JPopupMenu/4966112/bug4966112.java + test/javax/swing/JPopupMenu/6217905/bug6217905.java + test/javax/swing/JPopupMenu/6415145/bug6415145.java + test/javax/swing/JPopupMenu/6515446/bug6515446.java + test/javax/swing/JPopupMenu/6544309/bug6544309.java + test/javax/swing/JPopupMenu/6580930/bug6580930.java ! test/javax/swing/JPopupMenu/6800513/bug6800513.java ! test/javax/swing/JPopupMenu/6827786/bug6827786.java ! test/javax/swing/JPopupMenu/6987844/bug6987844.java ! test/javax/swing/JPopupMenu/7154841/bug7154841.java ! test/javax/swing/JRadioButton/8033699/bug8033699.java ! test/javax/swing/JRootPane/4670486/bug4670486.java ! test/javax/swing/JScrollBar/4708809/bug4708809.java ! test/javax/swing/JScrollBar/6542335/bug6542335.java ! test/javax/swing/JScrollBar/7163696/Test7163696.java ! test/javax/swing/JScrollBar/bug4202954/bug4202954.java ! test/javax/swing/JSlider/6348946/bug6348946.java + test/javax/swing/JSlider/6401380/bug6401380.java ! test/javax/swing/JSlider/6848475/bug6848475.java ! test/javax/swing/JSpinner/4973721/bug4973721.java ! test/javax/swing/JSpinner/5012888/bug5012888.java ! test/javax/swing/JSplitPane/4885629/bug4885629.java ! test/javax/swing/JTabbedPane/4361477/bug4361477.java ! test/javax/swing/JTabbedPane/4624207/bug4624207.java ! test/javax/swing/JTabbedPane/6495408/bug6495408.java ! test/javax/swing/JTabbedPane/7161568/bug7161568.java ! test/javax/swing/JTable/4220171/bug4220171.java ! test/javax/swing/JTable/6263446/bug6263446.java ! test/javax/swing/JTable/6777378/bug6777378.java ! test/javax/swing/JTable/7055065/bug7055065.java ! test/javax/swing/JTable/7068740/bug7068740.java ! test/javax/swing/JTableHeader/6884066/bug6884066.java ! test/javax/swing/JTableHeader/6889007/bug6889007.java ! test/javax/swing/JTextArea/4697612/bug4697612.java ! test/javax/swing/JTextField/8036819/bug8036819.java ! test/javax/swing/JToolBar/4247996/bug4247996.java ! test/javax/swing/JToolTip/4846413/bug4846413.java ! test/javax/swing/JTree/4330357/bug4330357.java ! test/javax/swing/JTree/4908142/bug4908142.java ! test/javax/swing/JTree/4927934/bug4927934.java ! test/javax/swing/JTree/6263446/bug6263446.java ! test/javax/swing/JTree/6505523/bug6505523.java + test/javax/swing/JTree/6578666/bug6578666.java ! test/javax/swing/JTree/8003400/Test8003400.java ! test/javax/swing/JTree/8004298/bug8004298.java ! test/javax/swing/Popup/TaskbarPositionTest.java ! test/javax/swing/PopupFactory/6276087/NonOpaquePopupMenuTest.java ! test/javax/swing/SwingUtilities/4917669/bug4917669.java ! test/javax/swing/SwingUtilities/7146377/bug7146377.java ! test/javax/swing/ToolTipManager/Test6256140.java ! test/javax/swing/dnd/7171812/bug7171812.java ! test/javax/swing/plaf/basic/BasicHTML/4251579/bug4251579.java ! test/javax/swing/plaf/basic/BasicMenuUI/4983388/bug4983388.java ! test/javax/swing/plaf/basic/BasicTreeUI/8023474/bug8023474.java ! test/javax/swing/plaf/synth/7158712/bug7158712.java ! test/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java ! test/javax/swing/plaf/windows/WindowsRootPaneUI/WrongAltProcessing/WrongAltProcessing.java ! test/javax/swing/text/AbstractDocument/6968363/Test6968363.java ! test/javax/swing/text/CSSBorder/6796710/bug6796710.java ! test/javax/swing/text/DefaultEditorKit/4278839/bug4278839.java ! test/javax/swing/text/JTextComponent/5074573/bug5074573.java ! test/javax/swing/text/StyledEditorKit/4506788/bug4506788.java ! test/javax/swing/text/View/8014863/bug8014863.java ! test/javax/swing/text/html/CSS/4530474/bug4530474.java ! test/javax/swing/text/html/HTMLEditorKit/5043626/bug5043626.java Changeset: 3b4fb96700f5 Author: andrew Date: 2020-11-27 03:51 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/3b4fb96700f5 Merge - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/AbsoluteComponentCenterCalculator.java - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/DataFlavorSearcher.java - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/InterprocessMessages.java - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.html - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.java - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MyTransferable.java - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/NextFramePositionCalculator.java - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/SourcePanel.java - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/TargetPanel.java - test/java/awt/Mixing/AWT_Mixing/Util.java - test/java/awt/Mouse/MaximizedFrameTest/MaximizedFrameTest.html - test/java/awt/datatransfer/DuplicatedNativesTest/DuplicatedNativesTest.java - test/java/awt/datatransfer/MappingGenerationTest/MappingGenerationTest.java Changeset: 9ac2bd4b53d8 Author: bobv Date: 2019-05-10 11:15 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/9ac2bd4b53d8 8221340: [TESTBUG] TestCgroupMetrics.java fails after fix for JDK-8219562 Reviewed-by: mseledtsov, rriggs ! src/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java ! test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java Changeset: 782926a8b595 Author: sgehwolf Date: 2019-03-13 20:07 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/782926a8b595 8220579: [Containers] SubSystem.java out of sync with osContainer_linux.cpp Reviewed-by: bobv, adinn ! src/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java Changeset: ec6d52cea1e6 Author: sgehwolf Date: 2020-11-30 10:24 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/ec6d52cea1e6 8257397: [TESTBUG] test/lib/containers/docker/Common.java refers to -Xlog:os+container=trace Reviewed-by: shade ! test/lib/jdk/test/lib/containers/docker/Common.java Changeset: 31185ebcc316 Author: bobv Date: 2019-03-19 12:29 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/31185ebcc316 8217766: Container Support doesn't work for some Join Controllers combinations Reviewed-by: rriggs, sgehwolf ! src/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java Changeset: b0b404c86143 Author: arapte Date: 2016-09-20 12:37 +0530 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/b0b404c86143 8166015: [PIT][TEST_BUG] stray character in java/awt/Focus/ModalDialogActivationTest/ModalDialogActivationTest.java Reviewed-by: aghaisas, ssadetsky ! test/java/awt/Focus/ModalDialogActivationTest/ModalDialogActivationTest.java Changeset: dd1d220caeaf Author: sgehwolf Date: 2020-04-17 14:48 +0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/dd1d220caeaf 8242480: Negative value may be returned by getFreeSwapSpaceSize() in the docker Reviewed-by: andrew ! src/solaris/classes/sun/management/OperatingSystemImpl.java + test/jdk/internal/platform/docker/GetFreeSwapSpaceSize.java + test/jdk/internal/platform/docker/TestGetFreeSwapSpaceSize.java Changeset: e488620e4191 Author: stooke Date: 2020-09-23 17:59 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/e488620e4191 8152545: Use preprocessor instead of compiling a program to generate native nio constants Reviewed-by: andrew ! make/gensrc/GensrcMisc.gmk - make/src/native/genconstants/ch/genSocketOptionRegistry.c - make/src/native/genconstants/fs/genSolarisConstants.c - make/src/native/genconstants/fs/genUnixConstants.c + src/share/classes/sun/nio/ch/SocketOptionRegistry.java.template + src/solaris/classes/sun/nio/fs/SolarisConstants.java.template + src/unix/classes/sun/nio/fs/UnixConstants.java.template Changeset: e7df66dc154c Author: mbaesken Date: 2020-06-08 09:29 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/e7df66dc154c 8246648: issue with OperatingSystemImpl getFreeSwapSpaceSize in docker after 8242480 Reviewed-by: bobv, sgehwolf ! src/solaris/classes/sun/management/OperatingSystemImpl.java Changeset: 78c875107d40 Author: evergizova Date: 2019-03-25 15:37 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/78c875107d40 8217362: Emergency dump does not work when disk=false is set Reviewed-by: phh, andrew ! test/jdk/jfr/jvm/TestDumpOnCrash.java Changeset: 16e83f454a64 Author: andrew Date: 2020-12-01 06:35 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/16e83f454a64 Added tag jdk8u282-b04 for changeset 78c875107d40 ! .hgtags Changeset: 290269aa7e08 Author: andrew Date: 2021-01-06 02:52 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/290269aa7e08 Merge jdk8u282-b04 ! .hgtags ! THIRD_PARTY_README ! make/CompileLaunchers.gmk ! make/gensrc/GensrcMisc.gmk - make/src/native/genconstants/ch/genSocketOptionRegistry.c - make/src/native/genconstants/fs/genSolarisConstants.c - make/src/native/genconstants/fs/genUnixConstants.c ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509SKI.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Reference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignature.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverDirectHTTP.java ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCryptoBinary.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! test/demo/zipfs/ZipFSTester.java - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/AbsoluteComponentCenterCalculator.java - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/DataFlavorSearcher.java - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/InterprocessMessages.java - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.html - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.java - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MyTransferable.java - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/NextFramePositionCalculator.java - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/SourcePanel.java - test/java/awt/DataFlavor/MissedHtmlAndRtfBug/TargetPanel.java - test/java/awt/Mixing/AWT_Mixing/Util.java - test/java/awt/Mouse/MaximizedFrameTest/MaximizedFrameTest.html ! test/java/awt/ScrollPane/ScrollPanePreferredSize/ScrollPanePreferredSize.java ! test/java/awt/TextArea/TextAreaTwicePack/TextAreaTwicePack.java - test/java/awt/datatransfer/DuplicatedNativesTest/DuplicatedNativesTest.java - test/java/awt/datatransfer/MappingGenerationTest/MappingGenerationTest.java ! test/javax/swing/JComponent/6683775/bug6683775.java ! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java ! test/javax/swing/PopupFactory/6276087/NonOpaquePopupMenuTest.java Changeset: 16378685e436 Author: andrew Date: 2021-01-06 02:52 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/16378685e436 Added tag aarch64-shenandoah-jdk8u282-b04 for changeset 290269aa7e08 ! .hgtags Changeset: 25cd39ef5b98 Author: andrew Date: 2020-12-03 16:43 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/25cd39ef5b98 8254982: (tz) Upgrade time-zone data to tzdata2020c Reviewed-by: phh ! make/data/tzdata/VERSION ! make/data/tzdata/australasia ! make/data/tzdata/europe ! test/java/util/Formatter/BasicDateTime.java ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/australasia ! test/sun/util/calendar/zi/tzdata/europe Changeset: 450c12c3c207 Author: andrew Date: 2020-12-09 02:47 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/450c12c3c207 Added tag jdk8u282-b05 for changeset 25cd39ef5b98 ! .hgtags Changeset: 2ea0157ba45c Author: andrew Date: 2021-01-10 23:25 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/2ea0157ba45c Merge jdk8u282-b05 ! .hgtags ! make/data/tzdata/VERSION ! make/data/tzdata/australasia ! make/data/tzdata/europe ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/australasia ! test/sun/util/calendar/zi/tzdata/europe Changeset: 100e43a8c339 Author: andrew Date: 2021-01-10 23:26 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/100e43a8c339 Added tag aarch64-shenandoah-jdk8u282-b05 for changeset 2ea0157ba45c ! .hgtags Changeset: ef358e4669db Author: andrew Date: 2020-12-11 17:06 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/ef358e4669db 8255226: (tz) Upgrade time-zone data to tzdata2020d Reviewed-by: sgehwolf ! make/data/tzdata/VERSION ! make/data/tzdata/asia ! make/data/tzdata/europe ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/asia ! test/sun/util/calendar/zi/tzdata/europe Changeset: 013fdf158bc4 Author: andrew Date: 2020-12-14 13:45 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/013fdf158bc4 Added tag jdk8u282-b06 for changeset ef358e4669db ! .hgtags Changeset: 1a90608ad0cc Author: andrew Date: 2021-01-13 04:30 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/1a90608ad0cc Merge jdk8u282-b06 ! .hgtags ! make/data/tzdata/VERSION ! make/data/tzdata/asia ! make/data/tzdata/europe ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/asia ! test/sun/util/calendar/zi/tzdata/europe Changeset: 8ef4549f6680 Author: andrew Date: 2021-01-13 04:30 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/8ef4549f6680 Added tag aarch64-shenandoah-jdk8u282-b06 for changeset 1a90608ad0cc ! .hgtags Changeset: 9b12c529e08c Author: rhalade Date: 2020-10-02 17:21 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/9b12c529e08c 8239105: Add exception for expiring Digicert root certificates to VerifyCACerts test Summary: "8239105: added verisigntsaca and thawtepremiumserverca to EXPIRY_EXC_ENTRIES list" Reviewed-by: mullan ! test/sun/security/lib/cacerts/VerifyCACerts.java Changeset: aa9f038a7034 Author: rhalade Date: 2020-12-17 20:27 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/aa9f038a7034 8225072: Add LuxTrust certificate that is expiring in March 2021 to list of allowed but expired certs 8258630: Add expiry exception for QuoVadis root certificate Reviewed-by: ascarpino ! test/sun/security/lib/cacerts/VerifyCACerts.java Changeset: 4b5e357b4beb Author: andrew Date: 2020-12-29 00:56 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/4b5e357b4beb Added tag jdk8u282-b07 for changeset aa9f038a7034 ! .hgtags Changeset: 99afe1461a65 Author: andrew Date: 2021-01-14 22:49 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/99afe1461a65 Merge jdk8u282-b07 ! .hgtags Changeset: 894c592a6a91 Author: andrew Date: 2021-01-14 22:50 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/894c592a6a91 Added tag aarch64-shenandoah-jdk8u282-b07 for changeset 99afe1461a65 ! .hgtags Changeset: 6fe9792e7893 Author: mbalao Date: 2020-07-29 09:52 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/6fe9792e7893 8247619: Improve Direct Buffering of Characters Reviewed-by: alanb, ahgross, rhalade, psandoz, andrew ! src/share/classes/java/nio/Buffer.java ! src/share/classes/java/nio/Heap-X-Buffer.java.template ! src/share/classes/java/nio/X-Buffer.java.template Changeset: 82e0f8292b63 Author: andrew Date: 2021-01-08 04:13 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/82e0f8292b63 Added tag jdk8u282-b08 for changeset 6fe9792e7893 ! .hgtags Changeset: 6d463c7d0ba9 Author: andrew Date: 2021-01-15 17:21 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/6d463c7d0ba9 Merge jdk8u282-b08 ! .hgtags ! src/share/classes/java/nio/X-Buffer.java.template Changeset: b54c25e76b6d Author: andrew Date: 2021-01-15 17:21 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/b54c25e76b6d Added tag aarch64-shenandoah-jdk8u282-b08 for changeset 6d463c7d0ba9 ! .hgtags From zgu at openjdk.java.net Tue Jan 26 20:28:41 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 26 Jan 2021 20:28:41 GMT Subject: Integrated: 8260421: Shenandoah: Fix conc_mark_roots timing name and indentations In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 16:55:02 GMT, Zhengyu Gu wrote: > Please review this trivial patch that renames conc_mark_roots timing name and fixes indentations > > Test: > - [x] hotspot_gc_shenandoah This pull request has now been integrated. Changeset: 1bebd418 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/1bebd418 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8260421: Shenandoah: Fix conc_mark_roots timing name and indentations Reviewed-by: rkennke, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/2241 From shade at openjdk.java.net Wed Jan 27 07:20:42 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 27 Jan 2021 07:20:42 GMT Subject: Integrated: 8260106: Shenandoah: refactor reference updating closures and related code In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 15:06:20 GMT, Aleksey Shipilev wrote: > We have a block in `ShenandoahHeap::maybe_update_with_forwarded` that is irrelevant after JDK-8231086. Additionally, "resolve and update" paths are really only used by STW GCs, and thus do not require atomic updates. This leads to considerable simplifications in the code, and improves performance on the common paths (especially in fastdebug builds that drop many irrelevant asserts). > > Additional testing: > - [x] `hotspot_gc_shenandoah` > - [x] `tier1` with Shenandoah > - [x] `tier2` with Shenandoah This pull request has now been integrated. Changeset: bd2744dd Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/bd2744dd Stats: 279 lines in 15 files changed: 86 ins; 116 del; 77 mod 8260106: Shenandoah: refactor reference updating closures and related code Reviewed-by: zgu, rkennke ------------- PR: https://git.openjdk.java.net/jdk/pull/2166 From rkennke at openjdk.java.net Wed Jan 27 12:54:46 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 27 Jan 2021 12:54:46 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code In-Reply-To: References: Message-ID: On Wed, 11 Nov 2020 19:00:52 GMT, Aleksey Shipilev wrote: > $ CONF=linux-x86-server-fastdebug make images run-test TEST=compiler/c1/Test6855215.java TEST_VM_OPTS="-XX:+UseShenandoahGC" > > # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3047), pid=1427307, tid=1427311 > # Error: assert(VM_Version::supports_sse2()) failed > > V [libjvm.so+0x53f9e8] Assembler::movsd(Address, XMMRegisterImpl*)+0x168 > V [libjvm.so+0x14647bd] save_xmm_registers(MacroAssembler*)+0x9d > V [libjvm.so+0x1465d8f] ShenandoahBarrierSetAssembler::load_reference_barrier(MacroAssembler*, RegisterImpl*, Address, ShenandoahBarrierSet::AccessKind)+0x91f > > This only affects x86_32, as x86_64 uses at least UseSSE >= 2 at all times. > > Additional testing: > - [ ] `tier1`, Linux x86_64 `-XX:+UseShenandoahGC` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=0` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=1` Nice change! See comment. Do we need to handle no-SSE case too? src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp line 127: > 125: __ get_thread(thread); > 126: #endif > 127: assert_different_registers(src, dst, count, thread); Take a look at methodHandles_x86.cpp, there is pushing/popping code like this: #ifdef _LP64 __ movdbl(Address(rsp, 0), xmm0); #else if (UseSSE >= 2) { __ movdbl(Address(rsp, 0), xmm0); } else if (UseSSE == 1) { __ movflt(Address(rsp, 0), xmm0); } else { __ fst_d(Address(rsp, 0)); } #endif // LP64 IOW, it also has a branch for no SSE at all. :-) BTW, I am almost certain that we only ever need to save/restore xmm0. The relevant code is (afaict) only ever called by the interpreter (which only uses xmm0) and methodHandles (which also only seems to care about xmm0 - see the various code sequences there 'save FP result'). Grep for load_heap_oop(), that gives all relevant entries. But that is outside the scope of this patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From shade at openjdk.java.net Wed Jan 27 12:54:46 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 27 Jan 2021 12:54:46 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code Message-ID: $ CONF=linux-x86-server-fastdebug make images run-test TEST=compiler/c1/Test6855215.java TEST_VM_OPTS="-XX:+UseShenandoahGC" # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3047), pid=1427307, tid=1427311 # Error: assert(VM_Version::supports_sse2()) failed V [libjvm.so+0x53f9e8] Assembler::movsd(Address, XMMRegisterImpl*)+0x168 V [libjvm.so+0x14647bd] save_xmm_registers(MacroAssembler*)+0x9d V [libjvm.so+0x1465d8f] ShenandoahBarrierSetAssembler::load_reference_barrier(MacroAssembler*, RegisterImpl*, Address, ShenandoahBarrierSet::AccessKind)+0x91f This only affects x86_32, as x86_64 uses at least UseSSE >= 2 at all times. Additional testing: - [ ] `tier1`, Linux x86_64 `-XX:+UseShenandoahGC` - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC` - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=0` - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=1` ------------- Commit messages: - Merge branch 'master' into JDK-8256215-shenandoah-no-sse2-fail - Simplify - Merge branch 'master' into JDK-8256215-shenandoah-no-sse2-fail - Merge branch 'master' into JDK-8256215-shenandoah-no-sse2-fail - Merge branch 'master' into JDK-8256215-shenandoah-no-sse2-fail - 8256215: Some x86_32 Shenandoah tests fail due to using unsupported SSE2 instructions Changes: https://git.openjdk.java.net/jdk/pull/1172/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1172&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256215 Stats: 118 lines in 2 files changed: 69 ins; 13 del; 36 mod Patch: https://git.openjdk.java.net/jdk/pull/1172.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1172/head:pull/1172 PR: https://git.openjdk.java.net/jdk/pull/1172 From rkennke at openjdk.java.net Wed Jan 27 12:54:47 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 27 Jan 2021 12:54:47 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 21:42:52 GMT, Roman Kennke wrote: >> $ CONF=linux-x86-server-fastdebug make images run-test TEST=compiler/c1/Test6855215.java TEST_VM_OPTS="-XX:+UseShenandoahGC" >> >> # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3047), pid=1427307, tid=1427311 >> # Error: assert(VM_Version::supports_sse2()) failed >> >> V [libjvm.so+0x53f9e8] Assembler::movsd(Address, XMMRegisterImpl*)+0x168 >> V [libjvm.so+0x14647bd] save_xmm_registers(MacroAssembler*)+0x9d >> V [libjvm.so+0x1465d8f] ShenandoahBarrierSetAssembler::load_reference_barrier(MacroAssembler*, RegisterImpl*, Address, ShenandoahBarrierSet::AccessKind)+0x91f >> >> This only affects x86_32, as x86_64 uses at least UseSSE >= 2 at all times. >> >> Additional testing: >> - [ ] `tier1`, Linux x86_64 `-XX:+UseShenandoahGC` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=0` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=1` > > src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp line 127: > >> 125: __ get_thread(thread); >> 126: #endif >> 127: assert_different_registers(src, dst, count, thread); > > Take a look at methodHandles_x86.cpp, there is pushing/popping code like this: > #ifdef _LP64 > __ movdbl(Address(rsp, 0), xmm0); > #else > if (UseSSE >= 2) { > __ movdbl(Address(rsp, 0), xmm0); > } else if (UseSSE == 1) { > __ movflt(Address(rsp, 0), xmm0); > } else { > __ fst_d(Address(rsp, 0)); > } > #endif // LP64 > > IOW, it also has a branch for no SSE at all. :-) > > BTW, I am almost certain that we only ever need to save/restore xmm0. The relevant code is (afaict) only ever called by the interpreter (which only uses xmm0) and methodHandles (which also only seems to care about xmm0 - see the various code sequences there 'save FP result'). Grep for load_heap_oop(), that gives all relevant entries. But that is outside the scope of this patch. To extend a little bit on that last comment: we introduced that xmm save/restore code when we still had RBs and WBs, and we needed a WB in front of C1's CAS-obj. That would mess with C1 keeping FP values in xmm registers across the then-WB. With the move to LRB, this was no longer necessary, and all remaining calls into the asm LRB routines are from the interpreter and thus only need to save/restore xmm0 (which could reasonably be folded into save/restore of other registers and save one add/sub each). The C1 LRB stub calls C1_MacroAssembler::save_live_registers_no_oop_map() which is already smart about which registers to save in context of C1. ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From zgu at openjdk.java.net Wed Jan 27 13:08:40 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 27 Jan 2021 13:08:40 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code In-Reply-To: References: Message-ID: On Wed, 11 Nov 2020 19:00:52 GMT, Aleksey Shipilev wrote: > $ CONF=linux-x86-server-fastdebug make images run-test TEST=compiler/c1/Test6855215.java TEST_VM_OPTS="-XX:+UseShenandoahGC" > > # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3047), pid=1427307, tid=1427311 > # Error: assert(VM_Version::supports_sse2()) failed > > V [libjvm.so+0x53f9e8] Assembler::movsd(Address, XMMRegisterImpl*)+0x168 > V [libjvm.so+0x14647bd] save_xmm_registers(MacroAssembler*)+0x9d > V [libjvm.so+0x1465d8f] ShenandoahBarrierSetAssembler::load_reference_barrier(MacroAssembler*, RegisterImpl*, Address, ShenandoahBarrierSet::AccessKind)+0x91f > > This only affects x86_32, as x86_64 uses at least UseSSE >= 2 at all times. > > Additional testing: > - [ ] `tier1`, Linux x86_64 `-XX:+UseShenandoahGC` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=0` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=1` Probably, no processor that does not support sse2, but should we always use VM_version::supports_sse(x)? instead of UseSSE(x) ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From shade at openjdk.java.net Wed Jan 27 13:11:40 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 27 Jan 2021 13:11:40 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code In-Reply-To: References: Message-ID: <-SCzTLsHYdhLesTYEry9DQ5-kqQhbymWMzUlFhzD_1A=.c1858ed0-1373-41b7-8bd5-a9ec94a4a38f@github.com> On Wed, 27 Jan 2021 13:06:04 GMT, Zhengyu Gu wrote: > Probably, no processor that does not support sse2, but should we always use VM_version::supports_sse(x)? instead of UseSSE(x) "Hotspot way" seems to be "check for VM_version::supports_sse* in assemblers" + "check for appropriate UseSSE level in machine-specific code before asking assemblers". This is what the patch does. ...or I misunderstand the question. ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From rkennke at openjdk.java.net Wed Jan 27 14:59:43 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 27 Jan 2021 14:59:43 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code In-Reply-To: References: Message-ID: On Wed, 11 Nov 2020 19:00:52 GMT, Aleksey Shipilev wrote: > $ CONF=linux-x86-server-fastdebug make images run-test TEST=compiler/c1/Test6855215.java TEST_VM_OPTS="-XX:+UseShenandoahGC" > > # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3047), pid=1427307, tid=1427311 > # Error: assert(VM_Version::supports_sse2()) failed > > V [libjvm.so+0x53f9e8] Assembler::movsd(Address, XMMRegisterImpl*)+0x168 > V [libjvm.so+0x14647bd] save_xmm_registers(MacroAssembler*)+0x9d > V [libjvm.so+0x1465d8f] ShenandoahBarrierSetAssembler::load_reference_barrier(MacroAssembler*, RegisterImpl*, Address, ShenandoahBarrierSet::AccessKind)+0x91f > > This only affects x86_32, as x86_64 uses at least UseSSE >= 2 at all times. > > Additional testing: > - [ ] `tier1`, Linux x86_64 `-XX:+UseShenandoahGC` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=0` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=1` Looks good, but I have questions. src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp line 159: > 157: __ jcc(Assembler::zero, done); > 158: > 159: save_machine_state(masm, /* handle_gpr = */ true, /* handle_fp = */ true); IIRC, it is ensured in arraycopy prologue and epilogue that no FPU state is active (I can probably research why), and it may affect performance of tiny arraycopies (which are more frequent than I'd like). src/hotspot/cpu/x86/stubGenerator_x86_32.cpp line 3683: > 3681: __ movflt(Address(rsp, xmm_size * 1), xmm1); > 3682: __ movflt(Address(rsp, xmm_size * 0), xmm0); > 3683: } I am not sure that we should sneak in this shared-code change with what is otherwise a Shenandoah-change. ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From shade at openjdk.java.net Wed Jan 27 15:04:42 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 27 Jan 2021 15:04:42 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code In-Reply-To: References: Message-ID: <2L7t0PoVLBOxTLjkA5By5XbMkiEY1L2jaEDuEeZMWPQ=.cf32eda1-4163-4d64-abad-b8fc5ab37374@github.com> On Wed, 27 Jan 2021 14:54:24 GMT, Roman Kennke wrote: >> $ CONF=linux-x86-server-fastdebug make images run-test TEST=compiler/c1/Test6855215.java TEST_VM_OPTS="-XX:+UseShenandoahGC" >> >> # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3047), pid=1427307, tid=1427311 >> # Error: assert(VM_Version::supports_sse2()) failed >> >> V [libjvm.so+0x53f9e8] Assembler::movsd(Address, XMMRegisterImpl*)+0x168 >> V [libjvm.so+0x14647bd] save_xmm_registers(MacroAssembler*)+0x9d >> V [libjvm.so+0x1465d8f] ShenandoahBarrierSetAssembler::load_reference_barrier(MacroAssembler*, RegisterImpl*, Address, ShenandoahBarrierSet::AccessKind)+0x91f >> >> This only affects x86_32, as x86_64 uses at least UseSSE >= 2 at all times. >> >> Additional testing: >> - [ ] `tier1`, Linux x86_64 `-XX:+UseShenandoahGC` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=0` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=1` > > src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp line 159: > >> 157: __ jcc(Assembler::zero, done); >> 158: >> 159: save_machine_state(masm, /* handle_gpr = */ true, /* handle_fp = */ true); > > IIRC, it is ensured in arraycopy prologue and epilogue that no FPU state is active (I can probably research why), and it may affect performance of tiny arraycopies (which are more frequent than I'd like). OK, I was going for the overkill of over-saving registers for interpreter code. But you are right, this might be problematic. We could do `/* handle_fp = */ false` here, so it would save only the generic registers? > src/hotspot/cpu/x86/stubGenerator_x86_32.cpp line 3683: > >> 3681: __ movflt(Address(rsp, xmm_size * 1), xmm1); >> 3682: __ movflt(Address(rsp, xmm_size * 0), xmm0); >> 3683: } > > I am not sure that we should sneak in this shared-code change with what is otherwise a Shenandoah-change. This is nmethod barrier handling part, and on x86_32, Shenandoah is the only user of this code. I can split it out, but it would still be Shenandoah-specific. ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From rkennke at openjdk.java.net Wed Jan 27 15:04:43 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 27 Jan 2021 15:04:43 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code In-Reply-To: <2L7t0PoVLBOxTLjkA5By5XbMkiEY1L2jaEDuEeZMWPQ=.cf32eda1-4163-4d64-abad-b8fc5ab37374@github.com> References: <2L7t0PoVLBOxTLjkA5By5XbMkiEY1L2jaEDuEeZMWPQ=.cf32eda1-4163-4d64-abad-b8fc5ab37374@github.com> Message-ID: On Wed, 27 Jan 2021 14:59:59 GMT, Aleksey Shipilev wrote: >> src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp line 159: >> >>> 157: __ jcc(Assembler::zero, done); >>> 158: >>> 159: save_machine_state(masm, /* handle_gpr = */ true, /* handle_fp = */ true); >> >> IIRC, it is ensured in arraycopy prologue and epilogue that no FPU state is active (I can probably research why), and it may affect performance of tiny arraycopies (which are more frequent than I'd like). > > OK, I was going for the overkill of over-saving registers for interpreter code. But you are right, this might be problematic. We could do `/* handle_fp = */ false` here, so it would save only the generic registers? Ah yes, Look in stubGenerator_x86_64, copy_bytes_forward() and copy_bytes_backward(), those generate fast copy routines that use FP registers. If those registers were live in the arraycopy code paths, those routines would trash it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From shade at openjdk.java.net Wed Jan 27 15:12:43 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 27 Jan 2021 15:12:43 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code In-Reply-To: References: <2L7t0PoVLBOxTLjkA5By5XbMkiEY1L2jaEDuEeZMWPQ=.cf32eda1-4163-4d64-abad-b8fc5ab37374@github.com> Message-ID: On Wed, 27 Jan 2021 15:02:12 GMT, Roman Kennke wrote: >> OK, I was going for the overkill of over-saving registers for interpreter code. But you are right, this might be problematic. We could do `/* handle_fp = */ false` here, so it would save only the generic registers? > > Ah yes, Look in stubGenerator_x86_64, copy_bytes_forward() and copy_bytes_backward(), those generate fast copy routines that use FP registers. If those registers were live in the arraycopy code paths, those routines would trash it. Yes, so that basically confirms the current behavior (that is, not saving FP) is already OK. I'll drop `handle_fp` to `false` then. ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From shade at openjdk.java.net Wed Jan 27 15:17:45 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 27 Jan 2021 15:17:45 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code In-Reply-To: <2L7t0PoVLBOxTLjkA5By5XbMkiEY1L2jaEDuEeZMWPQ=.cf32eda1-4163-4d64-abad-b8fc5ab37374@github.com> References: <2L7t0PoVLBOxTLjkA5By5XbMkiEY1L2jaEDuEeZMWPQ=.cf32eda1-4163-4d64-abad-b8fc5ab37374@github.com> Message-ID: On Wed, 27 Jan 2021 15:00:29 GMT, Aleksey Shipilev wrote: >> src/hotspot/cpu/x86/stubGenerator_x86_32.cpp line 3683: >> >>> 3681: __ movflt(Address(rsp, xmm_size * 1), xmm1); >>> 3682: __ movflt(Address(rsp, xmm_size * 0), xmm0); >>> 3683: } >> >> I am not sure that we should sneak in this shared-code change with what is otherwise a Shenandoah-change. > > This is nmethod barrier handling part, and on x86_32, Shenandoah is the only user of this code. I can split it out, but it would still be Shenandoah-specific. (...and I don't like to split it, because both hunks are needed to pass testing) ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From shade at openjdk.java.net Wed Jan 27 15:26:57 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 27 Jan 2021 15:26:57 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code [v2] In-Reply-To: References: Message-ID: > $ CONF=linux-x86-server-fastdebug make images run-test TEST=compiler/c1/Test6855215.java TEST_VM_OPTS="-XX:+UseShenandoahGC" > > # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3047), pid=1427307, tid=1427311 > # Error: assert(VM_Version::supports_sse2()) failed > > V [libjvm.so+0x53f9e8] Assembler::movsd(Address, XMMRegisterImpl*)+0x168 > V [libjvm.so+0x14647bd] save_xmm_registers(MacroAssembler*)+0x9d > V [libjvm.so+0x1465d8f] ShenandoahBarrierSetAssembler::load_reference_barrier(MacroAssembler*, RegisterImpl*, Address, ShenandoahBarrierSet::AccessKind)+0x91f > > This only affects x86_32, as x86_64 uses at least UseSSE >= 2 at all times. > > Additional testing: > - [ ] `tier1`, Linux x86_64 `-XX:+UseShenandoahGC` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=0` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=1` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Drop FP reg saves for arraycopy (current behavior) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1172/files - new: https://git.openjdk.java.net/jdk/pull/1172/files/b4db69e5..489c0db7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1172&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1172&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1172.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1172/head:pull/1172 PR: https://git.openjdk.java.net/jdk/pull/1172 From rkennke at openjdk.java.net Wed Jan 27 15:38:50 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 27 Jan 2021 15:38:50 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code [v2] In-Reply-To: References: <2L7t0PoVLBOxTLjkA5By5XbMkiEY1L2jaEDuEeZMWPQ=.cf32eda1-4163-4d64-abad-b8fc5ab37374@github.com> Message-ID: On Wed, 27 Jan 2021 15:02:12 GMT, Roman Kennke wrote: >> OK, I was going for the overkill of over-saving registers for interpreter code. But you are right, this might be problematic. We could do `/* handle_fp = */ false` here, so it would save only the generic registers? > > Ah yes, Look in stubGenerator_x86_64, copy_bytes_forward() and copy_bytes_backward(), those generate fast copy routines that use FP registers. If those registers were live in the arraycopy code paths, those routines would trash it. Yes, save only generic regs there should be good. ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From rkennke at openjdk.java.net Wed Jan 27 15:38:49 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 27 Jan 2021 15:38:49 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code [v2] In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 15:26:57 GMT, Aleksey Shipilev wrote: >> $ CONF=linux-x86-server-fastdebug make images run-test TEST=compiler/c1/Test6855215.java TEST_VM_OPTS="-XX:+UseShenandoahGC" >> >> # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3047), pid=1427307, tid=1427311 >> # Error: assert(VM_Version::supports_sse2()) failed >> >> V [libjvm.so+0x53f9e8] Assembler::movsd(Address, XMMRegisterImpl*)+0x168 >> V [libjvm.so+0x14647bd] save_xmm_registers(MacroAssembler*)+0x9d >> V [libjvm.so+0x1465d8f] ShenandoahBarrierSetAssembler::load_reference_barrier(MacroAssembler*, RegisterImpl*, Address, ShenandoahBarrierSet::AccessKind)+0x91f >> >> This only affects x86_32, as x86_64 uses at least UseSSE >= 2 at all times. >> >> Additional testing: >> - [ ] `tier1`, Linux x86_64 `-XX:+UseShenandoahGC` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=0` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=1` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Drop FP reg saves for arraycopy (current behavior) Looks good to me! Thanks! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1172 From rkennke at openjdk.java.net Wed Jan 27 15:38:52 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 27 Jan 2021 15:38:52 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code [v2] In-Reply-To: <2L7t0PoVLBOxTLjkA5By5XbMkiEY1L2jaEDuEeZMWPQ=.cf32eda1-4163-4d64-abad-b8fc5ab37374@github.com> References: <2L7t0PoVLBOxTLjkA5By5XbMkiEY1L2jaEDuEeZMWPQ=.cf32eda1-4163-4d64-abad-b8fc5ab37374@github.com> Message-ID: On Wed, 27 Jan 2021 15:00:29 GMT, Aleksey Shipilev wrote: >> src/hotspot/cpu/x86/stubGenerator_x86_32.cpp line 3683: >> >>> 3681: __ movflt(Address(rsp, xmm_size * 1), xmm1); >>> 3682: __ movflt(Address(rsp, xmm_size * 0), xmm0); >>> 3683: } >> >> I am not sure that we should sneak in this shared-code change with what is otherwise a Shenandoah-change. > > This is nmethod barrier handling part, and on x86_32, Shenandoah is the only user of this code. I can split it out, but it would still be Shenandoah-specific. Ah ok then. ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From rkennke at openjdk.java.net Wed Jan 27 15:47:51 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 27 Jan 2021 15:47:51 GMT Subject: RFR: 8260497: Shenandoah: Improve SATB flushing Message-ID: Currently, we periodically force flushing of SATB queues. This works by activating a flag every 100ms in every thread, which causes that thread to enqueue its SATB buffer the next time it overflows, even if it doesn't meet its threshold after filtering. This is somewhat problematic when a thread does not actually overflow its SATB queue in time. The whole point of the exercise is to try and avoid having too much left-over work when we reach final-mark. We can do better than that: when concurrent mark is done we can handshake all threads, and let them flush their respective SATB queues, and re-enter concurrent mark loop again, until flushing yields no more work. Experiments show that it usually takes 1-3 flushes to clean out leftover work properly. I ran benchmarks, 3 high-pressure preset runs of SPECjbb2015, 10 minutes each: baseline: Finish Mark = 0,251 s (a = 688 us) (n = 364) (lvls, us = 125, 486, 621, 824, 4156) Finish Mark = 0,338 s (a = 922 us) (n = 366) (lvls, us = 131, 494, 652, 852, 72948) Finish Mark = 0,257 s (a = 699 us) (n = 368) (lvls, us = 111, 492, 645, 826, 4447) patched: Finish Mark = 0,112 s (a = 301 us) (n = 370) (lvls, us = 115, 207, 250, 281, 3709) Finish Mark = 0,107 s (a = 292 us) (n = 368) (lvls, us = 107, 209, 248, 287, 3329) Finish Mark = 0,114 s (a = 310 us) (n = 367) (lvls, us = 115, 211, 254, 285, 3819) It reliably lowers all timings for finish-mark. It also doesn't cause any regressions in throughput. Testing: - [x] hotspot_gc_shenandoah - [x] benchmarks ------------- Commit messages: - Some typing touch-ups - Merge remote-tracking branch 'upstream/master' into conc-flush-satb - Some cleanups, according to Aleksey's suggestions - Use SATBMarkQueue's enqueued counter; Aleksey's comments - Remove some more unrelated changes - Remove unrelated changes - Merge branch 'master' into conc-flush-satb - Remove old force-flush impl; retry until no more SATB enqueues - Simpler flushing - Merge branch 'master' into conc-flush-satb - ... and 2 more: https://git.openjdk.java.net/jdk/compare/7ed591cc...8df11fc1 Changes: https://git.openjdk.java.net/jdk/pull/2254/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2254&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260497 Stats: 94 lines in 10 files changed: 30 ins; 59 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2254.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2254/head:pull/2254 PR: https://git.openjdk.java.net/jdk/pull/2254 From shade at openjdk.java.net Wed Jan 27 15:47:53 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 27 Jan 2021 15:47:53 GMT Subject: RFR: 8260497: Shenandoah: Improve SATB flushing In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 10:15:19 GMT, Roman Kennke wrote: > Currently, we periodically force flushing of SATB queues. This works by activating a flag every 100ms in every thread, which causes that thread to enqueue its SATB buffer the next time it overflows, even if it doesn't meet its threshold after filtering. This is somewhat problematic when a thread does not actually overflow its SATB queue in time. The whole point of the exercise is to try and avoid having too much left-over work when we reach final-mark. > > We can do better than that: when concurrent mark is done we can handshake all threads, and let them flush their respective SATB queues, and re-enter concurrent mark loop again, until flushing yields no more work. Experiments show that it usually takes 1-3 flushes to clean out leftover work properly. > > I ran benchmarks, 3 high-pressure preset runs of SPECjbb2015, 10 minutes each: > > baseline: > Finish Mark = 0,251 s (a = 688 us) (n = 364) (lvls, us = 125, 486, 621, 824, 4156) > Finish Mark = 0,338 s (a = 922 us) (n = 366) (lvls, us = 131, 494, 652, 852, 72948) > Finish Mark = 0,257 s (a = 699 us) (n = 368) (lvls, us = 111, 492, 645, 826, 4447) > > patched: > Finish Mark = 0,112 s (a = 301 us) (n = 370) (lvls, us = 115, 207, 250, 281, 3709) > Finish Mark = 0,107 s (a = 292 us) (n = 368) (lvls, us = 107, 209, 248, 287, 3329) > Finish Mark = 0,114 s (a = 310 us) (n = 367) (lvls, us = 115, 211, 254, 285, 3819) > > It reliably lowers all timings for finish-mark. It also doesn't cause any regressions in throughput. > > Testing: > - [x] hotspot_gc_shenandoah > - [x] benchmarks Changes requested by shade (Reviewer). Changes requested by shade (Reviewer). This looks nice. Although you want to fix some of the build falures: https://github.com/rkennke/jdk/runs/1776231024?check_suite_focus=true Changes requested by shade (Reviewer). This looks good to me! src/hotspot/share/gc/shared/satbMarkQueue.hpp line 118: > 116: // Return true if the queue's buffer should be enqueued, even if not full. > 117: // The default method uses the buffer enqueue threshold. > 118: bool should_enqueue_buffer(SATBMarkQueue& queue); Why drop `virtual` here? Is it because Shenandoah was the only virtual override of it, and now we can do the non-virtual call? src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.cpp line 59: > 57: void ShenandoahSATBMarkQueueSet::enqueue_completed_buffer(BufferNode* node) { > 58: SATBMarkQueueSet::enqueue_completed_buffer(node); > 59: Atomic::inc(&_enqueued_count); I believe `SATBMarkQueueSet` already tracks this, and we could instead use `SATBMarkQueueSet::completed_buffers_num`? src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 256: > 254: > 255: ShenandoahFlushSATBHandshakeClosure flush_satb; > 256: ShenandoahSATBMarkQueueSet& qset = ShenandoahBarrierSet::satb_mark_queue_set(); Since you have the `qset` here, you might as well pass it to closure. src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.hpp line 35: > 33: class ShenandoahSATBMarkQueueSet : public SATBMarkQueueSet { > 34: private: > 35: volatile int _enqueued_count; I have a suspicion that `int` would overflow at some point in the long-running application. `size_t` would fit better, but then see the other comment that `SATBMQ` already tracks it itself. src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 266: > 264: workers->run_task(&task); > 265: > 266: enqueued_count_before = qset.completed_buffers_num(); Suggestion for names: `completed_before`, `completed_after`. src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 270: > 268: enqueued_count_after = qset.completed_buffers_num(); > 269: flushes++; > 270: } while (enqueued_count_before != enqueued_count_after && flushes < max_flushes); So, how does this interact with cancellation? Shouldn't we check for `cancelled_gc()` here as well? src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 257: > 255: ShenandoahSATBMarkQueueSet& qset = ShenandoahBarrierSet::satb_mark_queue_set(); > 256: ShenandoahFlushSATBHandshakeClosure flush_satb(qset); > 257: for (int flushes = 0; flushes < ShenandoahMaxSATBBufferFlushes; flushes++) { Should probably be `uint` to match the unsigned `ShenandoahMaxSATBBufferFlushes`. src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 267: > 265: } > 266: > 267: int before = qset.completed_buffers_num(); Should probably be `size_t`. ------------- PR: https://git.openjdk.java.net/jdk/pull/2254Marked as reviewed by shade (Reviewer). From rkennke at openjdk.java.net Wed Jan 27 15:47:55 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 27 Jan 2021 15:47:55 GMT Subject: RFR: 8260497: Shenandoah: Improve SATB flushing In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 10:31:47 GMT, Aleksey Shipilev wrote: >> Currently, we periodically force flushing of SATB queues. This works by activating a flag every 100ms in every thread, which causes that thread to enqueue its SATB buffer the next time it overflows, even if it doesn't meet its threshold after filtering. This is somewhat problematic when a thread does not actually overflow its SATB queue in time. The whole point of the exercise is to try and avoid having too much left-over work when we reach final-mark. >> >> We can do better than that: when concurrent mark is done we can handshake all threads, and let them flush their respective SATB queues, and re-enter concurrent mark loop again, until flushing yields no more work. Experiments show that it usually takes 1-3 flushes to clean out leftover work properly. >> >> I ran benchmarks, 3 high-pressure preset runs of SPECjbb2015, 10 minutes each: >> >> baseline: >> Finish Mark = 0,251 s (a = 688 us) (n = 364) (lvls, us = 125, 486, 621, 824, 4156) >> Finish Mark = 0,338 s (a = 922 us) (n = 366) (lvls, us = 131, 494, 652, 852, 72948) >> Finish Mark = 0,257 s (a = 699 us) (n = 368) (lvls, us = 111, 492, 645, 826, 4447) >> >> patched: >> Finish Mark = 0,112 s (a = 301 us) (n = 370) (lvls, us = 115, 207, 250, 281, 3709) >> Finish Mark = 0,107 s (a = 292 us) (n = 368) (lvls, us = 107, 209, 248, 287, 3329) >> Finish Mark = 0,114 s (a = 310 us) (n = 367) (lvls, us = 115, 211, 254, 285, 3819) >> >> It reliably lowers all timings for finish-mark. It also doesn't cause any regressions in throughput. >> >> Testing: >> - [x] hotspot_gc_shenandoah >> - [x] benchmarks > > src/hotspot/share/gc/shared/satbMarkQueue.hpp line 118: > >> 116: // Return true if the queue's buffer should be enqueued, even if not full. >> 117: // The default method uses the buffer enqueue threshold. >> 118: bool should_enqueue_buffer(SATBMarkQueue& queue); > > Why drop `virtual` here? Is it because Shenandoah was the only virtual override of it, and now we can do the non-virtual call? Yes. IIRC we introduced that when we upstreamed Shenandoah, and can drop it again, thus restoring the original non-virtual version. > src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.cpp line 59: > >> 57: void ShenandoahSATBMarkQueueSet::enqueue_completed_buffer(BufferNode* node) { >> 58: SATBMarkQueueSet::enqueue_completed_buffer(node); >> 59: Atomic::inc(&_enqueued_count); > > I believe `SATBMarkQueueSet` already tracks this, and we could instead use `SATBMarkQueueSet::completed_buffers_num`? Ohh nice! Will give it a try! > src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.hpp line 35: > >> 33: class ShenandoahSATBMarkQueueSet : public SATBMarkQueueSet { >> 34: private: >> 35: volatile int _enqueued_count; > > I have a suspicion that `int` would overflow at some point in the long-running application. `size_t` would fit better, but then see the other comment that `SATBMQ` already tracks it itself. Right. (I only ever compare before != after, so overflow would be ok, but it doesn't matter b/c I'll remove it) ------------- PR: https://git.openjdk.java.net/jdk/pull/2254 From shade at openjdk.java.net Wed Jan 27 15:47:55 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 27 Jan 2021 15:47:55 GMT Subject: RFR: 8260497: Shenandoah: Improve SATB flushing In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 10:50:21 GMT, Roman Kennke wrote: >> src/hotspot/share/gc/shared/satbMarkQueue.hpp line 118: >> >>> 116: // Return true if the queue's buffer should be enqueued, even if not full. >>> 117: // The default method uses the buffer enqueue threshold. >>> 118: bool should_enqueue_buffer(SATBMarkQueue& queue); >> >> Why drop `virtual` here? Is it because Shenandoah was the only virtual override of it, and now we can do the non-virtual call? > > Yes. IIRC we introduced that when we upstreamed Shenandoah, and can drop it again, thus restoring the original non-virtual version. Okay then! ------------- PR: https://git.openjdk.java.net/jdk/pull/2254 From shade at openjdk.java.net Wed Jan 27 15:47:56 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 27 Jan 2021 15:47:56 GMT Subject: RFR: 8260497: Shenandoah: Improve SATB flushing In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 11:05:51 GMT, Aleksey Shipilev wrote: >> Currently, we periodically force flushing of SATB queues. This works by activating a flag every 100ms in every thread, which causes that thread to enqueue its SATB buffer the next time it overflows, even if it doesn't meet its threshold after filtering. This is somewhat problematic when a thread does not actually overflow its SATB queue in time. The whole point of the exercise is to try and avoid having too much left-over work when we reach final-mark. >> >> We can do better than that: when concurrent mark is done we can handshake all threads, and let them flush their respective SATB queues, and re-enter concurrent mark loop again, until flushing yields no more work. Experiments show that it usually takes 1-3 flushes to clean out leftover work properly. >> >> I ran benchmarks, 3 high-pressure preset runs of SPECjbb2015, 10 minutes each: >> >> baseline: >> Finish Mark = 0,251 s (a = 688 us) (n = 364) (lvls, us = 125, 486, 621, 824, 4156) >> Finish Mark = 0,338 s (a = 922 us) (n = 366) (lvls, us = 131, 494, 652, 852, 72948) >> Finish Mark = 0,257 s (a = 699 us) (n = 368) (lvls, us = 111, 492, 645, 826, 4447) >> >> patched: >> Finish Mark = 0,112 s (a = 301 us) (n = 370) (lvls, us = 115, 207, 250, 281, 3709) >> Finish Mark = 0,107 s (a = 292 us) (n = 368) (lvls, us = 107, 209, 248, 287, 3329) >> Finish Mark = 0,114 s (a = 310 us) (n = 367) (lvls, us = 115, 211, 254, 285, 3819) >> >> It reliably lowers all timings for finish-mark. It also doesn't cause any regressions in throughput. >> >> Testing: >> - [x] hotspot_gc_shenandoah >> - [x] benchmarks > > src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 270: > >> 268: enqueued_count_after = qset.completed_buffers_num(); >> 269: flushes++; >> 270: } while (enqueued_count_before != enqueued_count_after && flushes < max_flushes); > > So, how does this interact with cancellation? Shouldn't we check for `cancelled_gc()` here as well? I think this would be cleaner: ShenandoahFlushSATBHandshakeClosure flush_satb(qset); for (int flushes = 0; flushes < ShenandoahMaxSATBBufferFlushes; flushes++) { TaskTerminator terminator(nworkers, task_queues()); ShenandoahConcurrentMarkingTask task(this, &terminator); workers->run_task(&task); if (cancelled_gc()) { // GC is cancelled, break out. break; } int before = qset.completed_buffers_num(); Handshake::execute(&flush_satb); int after = qset.completed_buffers_num(); if (before == after) { // No more retries needed, break out. break; } } ------------- PR: https://git.openjdk.java.net/jdk/pull/2254 From zgu at openjdk.java.net Wed Jan 27 15:51:49 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 27 Jan 2021 15:51:49 GMT Subject: RFR: 8255837: Shenandoah: Remove ShenandoahConcurrentRoots class Message-ID: <0qG_GQeV5H4SJ-at5sZYqb9DfQXxB8iTKqu5Lrq9cX0=.dc182daf-dd84-453c-9f3b-e9cf81acfc02@github.com> The class was introduced for 2 purposes: 1) a platform supports concurrent class unloading (e.g. the platform supports nmethod_entry_barrier) 2) should perform concurrent class unloading for particular gc cycle (e.g. STW vs. concurrent GC) Now, concurrent class unloading is supported on all Shenandoah supported platforms. Furthermore, STW and concurrent GC are isolated (JDK-8255765), the class becomes superfluous. Test: - [x] hotspot_gc_shenandoah Linux x86_64 and x86_32 - [x] nightly ------------- Commit messages: - Fixed copyright years - Fixed merge issue - Update - Merge - ClassUnloading -> heap->unload_classes() - JDK-8255837 - Merge master - Merge branch 'JDK-8255765-isolate-gcs' into JDK-8256298-conc-stack-proc - Fixed indentation - More from Aleksey's review - ... and 127 more: https://git.openjdk.java.net/jdk/compare/fd00ed74...172438ec Changes: https://git.openjdk.java.net/jdk/pull/2262/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2262&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255837 Stats: 165 lines in 16 files changed: 0 ins; 124 del; 41 mod Patch: https://git.openjdk.java.net/jdk/pull/2262.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2262/head:pull/2262 PR: https://git.openjdk.java.net/jdk/pull/2262 From zgu at openjdk.java.net Wed Jan 27 16:02:43 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 27 Jan 2021 16:02:43 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code [v2] In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 15:36:09 GMT, Roman Kennke wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Drop FP reg saves for arraycopy (current behavior) > > Looks good to me! Thanks! > > Probably, no processor that does not support sse2, but should we always use VM_version::supports_sse(x)? instead of UseSSE(x) > > "Hotspot way" seems to be "check for VM_version::supports_sse* in assemblers" + "check for appropriate UseSSE level in machine-specific code before asking assemblers". This is what the patch does. ...or I misunderstand the question. Okay, then. ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From zgu at openjdk.java.net Wed Jan 27 16:02:41 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 27 Jan 2021 16:02:41 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code [v2] In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 15:26:57 GMT, Aleksey Shipilev wrote: >> $ CONF=linux-x86-server-fastdebug make images run-test TEST=compiler/c1/Test6855215.java TEST_VM_OPTS="-XX:+UseShenandoahGC" >> >> # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3047), pid=1427307, tid=1427311 >> # Error: assert(VM_Version::supports_sse2()) failed >> >> V [libjvm.so+0x53f9e8] Assembler::movsd(Address, XMMRegisterImpl*)+0x168 >> V [libjvm.so+0x14647bd] save_xmm_registers(MacroAssembler*)+0x9d >> V [libjvm.so+0x1465d8f] ShenandoahBarrierSetAssembler::load_reference_barrier(MacroAssembler*, RegisterImpl*, Address, ShenandoahBarrierSet::AccessKind)+0x91f >> >> This only affects x86_32, as x86_64 uses at least UseSSE >= 2 at all times. >> >> Additional testing: >> - [ ] `tier1`, Linux x86_64 `-XX:+UseShenandoahGC` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=0` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=1` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Drop FP reg saves for arraycopy (current behavior) Marked as reviewed by zgu (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From zgu at openjdk.java.net Wed Jan 27 16:04:40 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 27 Jan 2021 16:04:40 GMT Subject: RFR: 8260497: Shenandoah: Improve SATB flushing In-Reply-To: References: Message-ID: <_A61XN_bwigElezlBwG3GVF3up9pCswYqeOI8VjUN8k=.699ddc36-faf8-4485-92b4-e2781040f56d@github.com> On Wed, 27 Jan 2021 10:15:19 GMT, Roman Kennke wrote: > Currently, we periodically force flushing of SATB queues. This works by activating a flag every 100ms in every thread, which causes that thread to enqueue its SATB buffer the next time it overflows, even if it doesn't meet its threshold after filtering. This is somewhat problematic when a thread does not actually overflow its SATB queue in time. The whole point of the exercise is to try and avoid having too much left-over work when we reach final-mark. > > We can do better than that: when concurrent mark is done we can handshake all threads, and let them flush their respective SATB queues, and re-enter concurrent mark loop again, until flushing yields no more work. Experiments show that it usually takes 1-3 flushes to clean out leftover work properly. > > I ran benchmarks, 3 high-pressure preset runs of SPECjbb2015, 10 minutes each: > > baseline: > Finish Mark = 0,251 s (a = 688 us) (n = 364) (lvls, us = 125, 486, 621, 824, 4156) > Finish Mark = 0,338 s (a = 922 us) (n = 366) (lvls, us = 131, 494, 652, 852, 72948) > Finish Mark = 0,257 s (a = 699 us) (n = 368) (lvls, us = 111, 492, 645, 826, 4447) > > patched: > Finish Mark = 0,112 s (a = 301 us) (n = 370) (lvls, us = 115, 207, 250, 281, 3709) > Finish Mark = 0,107 s (a = 292 us) (n = 368) (lvls, us = 107, 209, 248, 287, 3329) > Finish Mark = 0,114 s (a = 310 us) (n = 367) (lvls, us = 115, 211, 254, 285, 3819) > > It reliably lowers all timings for finish-mark. It also doesn't cause any regressions in throughput. > > Testing: > - [x] hotspot_gc_shenandoah > - [x] benchmarks Marked as reviewed by zgu (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2254 From iveresov at openjdk.java.net Wed Jan 27 16:46:47 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Wed, 27 Jan 2021 16:46:47 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v5] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 18:13:20 GMT, Igor Veresov wrote: >> Looks better now. I would like to see result of performance testing before approving. > > I asked Eric to run the benchmarks. The results should be ready on Wednesday. The benchmarking is done. No regressions. There are mild improvements in startup benchmarks on the order of 1-5% (I suspect because of the compilation policy devirtualization). @dholmes-ora, do still plan to look at this? It's been a few weeks, I'd like to push this. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From shade at openjdk.java.net Wed Jan 27 17:02:50 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 27 Jan 2021 17:02:50 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v5] In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 16:43:28 GMT, Igor Veresov wrote: >> I asked Eric to run the benchmarks. The results should be ready on Wednesday. > > The benchmarking is done. No regressions. There are mild improvements in startup benchmarks on the order of 1-5% (I suspect because of the compilation policy devirtualization). > > @dholmes-ora, do still plan to look at this? It's been a few weeks, I'd like to push this. Please update from current master to get x86_32 built and tested in GH Actions. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Wed Jan 27 17:09:48 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 27 Jan 2021 17:09:48 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v5] In-Reply-To: References: Message-ID: On Sun, 24 Jan 2021 03:53:00 GMT, Igor Veresov wrote: >> This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> >> I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. >> >> Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Address Vladimir's review comments I approve it based on performance results. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Wed Jan 27 17:25:58 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Wed, 27 Jan 2021 17:25:58 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v6] In-Reply-To: References: Message-ID: > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. > > Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Address Vladimir's review comments - Check legacy flags validity before deriving flag values for emulation mode. - Fix another s390 compilation failure - Fix s390 build - Fix copyright years - Remove legacy compilation policy. ------------- Changes: https://git.openjdk.java.net/jdk/pull/1985/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=05 Stats: 5318 lines in 98 files changed: 1519 ins; 2994 del; 805 mod Patch: https://git.openjdk.java.net/jdk/pull/1985.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1985/head:pull/1985 PR: https://git.openjdk.java.net/jdk/pull/1985 From zgu at openjdk.java.net Wed Jan 27 18:21:59 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 27 Jan 2021 18:21:59 GMT Subject: RFR: 8260004: Shenandoah: Rename ShenandoahMarkCompact to ShenandoahFullGC Message-ID: Please review this patch that renames ShenandoahMarkCompact to ShenandoahFullGC, to be consistent with other GCs. ------------- Commit messages: - JDK-8260004-rename-fullgc Changes: https://git.openjdk.java.net/jdk/pull/2266/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2266&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260004 Stats: 38 lines in 9 files changed: 4 ins; 6 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/2266.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2266/head:pull/2266 PR: https://git.openjdk.java.net/jdk/pull/2266 From zgu at openjdk.java.net Wed Jan 27 18:27:00 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 27 Jan 2021 18:27:00 GMT Subject: RFR: 8260004: Shenandoah: Rename ShenandoahMarkCompact to ShenandoahFullGC [v2] In-Reply-To: References: Message-ID: <8OECF112bR0GUAr_PNDnJReQUqAgAQ687_os35TMeaY=.c061338c-6ddb-4f1f-a68f-b70de8b495e3@github.com> > Please review this patch that renames ShenandoahMarkCompact to ShenandoahFullGC, to be consistent with other GCs. Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge master - JDK-8260004-rename-fullgc ------------- Changes: https://git.openjdk.java.net/jdk/pull/2266/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2266&range=01 Stats: 38 lines in 9 files changed: 4 ins; 6 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/2266.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2266/head:pull/2266 PR: https://git.openjdk.java.net/jdk/pull/2266 From rkennke at openjdk.java.net Wed Jan 27 19:02:39 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 27 Jan 2021 19:02:39 GMT Subject: RFR: 8260004: Shenandoah: Rename ShenandoahMarkCompact to ShenandoahFullGC In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 18:16:09 GMT, Zhengyu Gu wrote: > Please review this patch that renames ShenandoahMarkCompact to ShenandoahFullGC, to be consistent with other GCs. This nomenclature might become problematic when generational Shenandoah becomes a thing. Then, what we do now, collecting the complete heap, as opposed to only the young generation, might be mistaken as 'full gc' too. ------------- PR: https://git.openjdk.java.net/jdk/pull/2266 From zgu at openjdk.java.net Wed Jan 27 21:04:39 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 27 Jan 2021 21:04:39 GMT Subject: RFR: 8260004: Shenandoah: Rename ShenandoahMarkCompact to ShenandoahFullGC In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 18:59:51 GMT, Roman Kennke wrote: > This nomenclature might become problematic when generational Shenandoah becomes a thing. Then, what we do now, collecting the complete heap, as opposed to only the young generation, might be mistaken as 'full gc' too. Does "full GC" always means complete heap collection? G1 calls it FullCollector and supporting classes all prefixing with FullGC ... ------------- PR: https://git.openjdk.java.net/jdk/pull/2266 From david.holmes at oracle.com Thu Jan 28 04:44:13 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Jan 2021 14:44:13 +1000 Subject: RFR: 8251462: Remove legacy compilation policy [v5] In-Reply-To: References: Message-ID: <7a846651-9ffe-eacd-af93-91f2e545b059@oracle.com> Hi Igor, On 28/01/2021 2:46 am, Igor Veresov wrote: > On Mon, 25 Jan 2021 18:13:20 GMT, Igor Veresov wrote: > >>> Looks better now. I would like to see result of performance testing before approving. >> >> I asked Eric to run the benchmarks. The results should be ready on Wednesday. > > The benchmarking is done. No regressions. There are mild improvements in startup benchmarks on the order of 1-5% (I suspect because of the compilation policy devirtualization). > > @dholmes-ora, do still plan to look at this? It's been a few weeks, I'd like to push this. No I only perused this and made a couple of comments, now addressed. I'll leave a full review to others. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1985 > From shade at openjdk.java.net Thu Jan 28 07:59:42 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 28 Jan 2021 07:59:42 GMT Subject: RFR: 8260004: Shenandoah: Rename ShenandoahMarkCompact to ShenandoahFullGC [v2] In-Reply-To: <8OECF112bR0GUAr_PNDnJReQUqAgAQ687_os35TMeaY=.c061338c-6ddb-4f1f-a68f-b70de8b495e3@github.com> References: <8OECF112bR0GUAr_PNDnJReQUqAgAQ687_os35TMeaY=.c061338c-6ddb-4f1f-a68f-b70de8b495e3@github.com> Message-ID: On Wed, 27 Jan 2021 18:27:00 GMT, Zhengyu Gu wrote: >> Please review this patch that renames ShenandoahMarkCompact to ShenandoahFullGC, to be consistent with other GCs. > > Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge master > - JDK-8260004-rename-fullgc Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2266 From shade at openjdk.java.net Thu Jan 28 07:59:43 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 28 Jan 2021 07:59:43 GMT Subject: RFR: 8260004: Shenandoah: Rename ShenandoahMarkCompact to ShenandoahFullGC In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 21:02:24 GMT, Zhengyu Gu wrote: >> This nomenclature might become problematic when generational Shenandoah becomes a thing. Then, what we do now, collecting the complete heap, as opposed to only the young generation, might be mistaken as 'full gc' too. > >> This nomenclature might become problematic when generational Shenandoah becomes a thing. Then, what we do now, collecting the complete heap, as opposed to only the young generation, might be mistaken as 'full gc' too. > > Does "full GC" always mean complete heap collection? G1 calls it FullCollector and supporting classes all prefix with FullGC ... I vote for this rename. We already report "Pause Full" for this operation, so it is "Full GC". The generational extension would probably call their phases "young" and "mixed" concurrent GC? ------------- PR: https://git.openjdk.java.net/jdk/pull/2266 From rkennke at openjdk.java.net Thu Jan 28 09:53:43 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 28 Jan 2021 09:53:43 GMT Subject: Integrated: 8260497: Shenandoah: Improve SATB flushing In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 10:15:19 GMT, Roman Kennke wrote: > Currently, we periodically force flushing of SATB queues. This works by activating a flag every 100ms in every thread, which causes that thread to enqueue its SATB buffer the next time it overflows, even if it doesn't meet its threshold after filtering. This is somewhat problematic when a thread does not actually overflow its SATB queue in time. The whole point of the exercise is to try and avoid having too much left-over work when we reach final-mark. > > We can do better than that: when concurrent mark is done we can handshake all threads, and let them flush their respective SATB queues, and re-enter concurrent mark loop again, until flushing yields no more work. Experiments show that it usually takes 1-3 flushes to clean out leftover work properly. > > I ran benchmarks, 3 high-pressure preset runs of SPECjbb2015, 10 minutes each: > > baseline: > Finish Mark = 0,251 s (a = 688 us) (n = 364) (lvls, us = 125, 486, 621, 824, 4156) > Finish Mark = 0,338 s (a = 922 us) (n = 366) (lvls, us = 131, 494, 652, 852, 72948) > Finish Mark = 0,257 s (a = 699 us) (n = 368) (lvls, us = 111, 492, 645, 826, 4447) > > patched: > Finish Mark = 0,112 s (a = 301 us) (n = 370) (lvls, us = 115, 207, 250, 281, 3709) > Finish Mark = 0,107 s (a = 292 us) (n = 368) (lvls, us = 107, 209, 248, 287, 3329) > Finish Mark = 0,114 s (a = 310 us) (n = 367) (lvls, us = 115, 211, 254, 285, 3819) > > It reliably lowers all timings for finish-mark. It also doesn't cause any regressions in throughput. > > Testing: > - [x] hotspot_gc_shenandoah > - [x] benchmarks This pull request has now been integrated. Changeset: 316d52c1 Author: Roman Kennke URL: https://git.openjdk.java.net/jdk/commit/316d52c1 Stats: 94 lines in 10 files changed: 30 ins; 59 del; 5 mod 8260497: Shenandoah: Improve SATB flushing Reviewed-by: shade, zgu ------------- PR: https://git.openjdk.java.net/jdk/pull/2254 From rkennke at openjdk.java.net Thu Jan 28 09:55:42 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 28 Jan 2021 09:55:42 GMT Subject: RFR: 8260004: Shenandoah: Rename ShenandoahMarkCompact to ShenandoahFullGC [v2] In-Reply-To: <8OECF112bR0GUAr_PNDnJReQUqAgAQ687_os35TMeaY=.c061338c-6ddb-4f1f-a68f-b70de8b495e3@github.com> References: <8OECF112bR0GUAr_PNDnJReQUqAgAQ687_os35TMeaY=.c061338c-6ddb-4f1f-a68f-b70de8b495e3@github.com> Message-ID: On Wed, 27 Jan 2021 18:27:00 GMT, Zhengyu Gu wrote: >> Please review this patch that renames ShenandoahMarkCompact to ShenandoahFullGC, to be consistent with other GCs. > > Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge master > - JDK-8260004-rename-fullgc Looks good to me! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2266 From rkennke at openjdk.java.net Thu Jan 28 09:55:45 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 28 Jan 2021 09:55:45 GMT Subject: RFR: 8260004: Shenandoah: Rename ShenandoahMarkCompact to ShenandoahFullGC [v2] In-Reply-To: References: <8OECF112bR0GUAr_PNDnJReQUqAgAQ687_os35TMeaY=.c061338c-6ddb-4f1f-a68f-b70de8b495e3@github.com> Message-ID: <3IEoNigLVUkdAY5VjNN-NWs2vY99DpWDUmtR9UBa4YU=.24aacfcc-7406-4ce9-9dcf-1863981b821a@github.com> On Thu, 28 Jan 2021 07:57:22 GMT, Aleksey Shipilev wrote: >> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: >> >> - Merge master >> - JDK-8260004-rename-fullgc > > Marked as reviewed by shade (Reviewer). > I vote for this rename. We already report "Pause Full" for this operation, so it is "Full GC". The generational extension would probably call their phases "young" and "mixed" concurrent GC? Yes ok. We can consider what to do when generational GC lands, if it is a problem at all. ------------- PR: https://git.openjdk.java.net/jdk/pull/2266 From shade at openjdk.java.net Thu Jan 28 10:27:40 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 28 Jan 2021 10:27:40 GMT Subject: Integrated: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code In-Reply-To: References: Message-ID: On Wed, 11 Nov 2020 19:00:52 GMT, Aleksey Shipilev wrote: > $ CONF=linux-x86-server-fastdebug make images run-test TEST=compiler/c1/Test6855215.java TEST_VM_OPTS="-XX:+UseShenandoahGC" > > # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3047), pid=1427307, tid=1427311 > # Error: assert(VM_Version::supports_sse2()) failed > > V [libjvm.so+0x53f9e8] Assembler::movsd(Address, XMMRegisterImpl*)+0x168 > V [libjvm.so+0x14647bd] save_xmm_registers(MacroAssembler*)+0x9d > V [libjvm.so+0x1465d8f] ShenandoahBarrierSetAssembler::load_reference_barrier(MacroAssembler*, RegisterImpl*, Address, ShenandoahBarrierSet::AccessKind)+0x91f > > This only affects x86_32, as x86_64 uses at least UseSSE >= 2 at all times. > > Additional testing: > - [ ] `tier1`, Linux x86_64 `-XX:+UseShenandoahGC` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=0` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=1` This pull request has now been integrated. Changeset: a97aedff Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/a97aedff Stats: 118 lines in 2 files changed: 69 ins; 13 del; 36 mod 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code Reviewed-by: rkennke, zgu ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From shade at openjdk.java.net Thu Jan 28 12:20:50 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 28 Jan 2021 12:20:50 GMT Subject: RFR: 8260584: Shenandoah: simplify "Concurrent Thread Roots" logging Message-ID: <_tmnF3EWmNl7yricNI7zUIGGOfcA52knD6hFUGzgTmg=.de301c69-4c25-44e0-a943-a5d778d8357a@github.com> There are two separate counters now: f(conc_thread_roots, "Concurrent Stack Processing") \ f(conc_thread_roots_work, " Threads") \ SHENANDOAH_PAR_PHASE_DO(conc_thread_roots_work_, " CT: ", f) \ ...and `_work` counter is unused, and `conc_thread_roots` is used to report worker stats. So the log says ``, where `Thread Roots` should have been mentioned: [34.169s][info][gc,stats] Concurrent Stack Processing 11341 us, parallelism: 7.93x [34.169s][info][gc,stats] Threads 89908 us [34.169s][info][gc,stats] CT: 89908 us, workers (us): 11231, 11270, 11251, 11252, 11237, 11230, 11214, 11223, Fixed log says: [99.797s][info][gc,stats] Concurrent Thread Roots 3929 us, parallelism: 7.45x [99.797s][info][gc,stats] CTR: 29273 us [99.797s][info][gc,stats] CTR: Thread Roots 29273 us, workers (us): 3652, 3643, 3622, 3623, 3623, 3676, 3606, 3829, Also, I believe it should be called "Concurrent Thread Roots", in symmetry with "Concurrent Update Thread Roots" later. ------------- Commit messages: - 8260584: Shenandoah: simplify "Concurrent Thread Roots" logging Changes: https://git.openjdk.java.net/jdk/pull/2287/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2287&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260584 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2287.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2287/head:pull/2287 PR: https://git.openjdk.java.net/jdk/pull/2287 From rkennke at openjdk.java.net Thu Jan 28 12:28:41 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 28 Jan 2021 12:28:41 GMT Subject: RFR: 8260584: Shenandoah: simplify "Concurrent Thread Roots" logging In-Reply-To: <_tmnF3EWmNl7yricNI7zUIGGOfcA52knD6hFUGzgTmg=.de301c69-4c25-44e0-a943-a5d778d8357a@github.com> References: <_tmnF3EWmNl7yricNI7zUIGGOfcA52knD6hFUGzgTmg=.de301c69-4c25-44e0-a943-a5d778d8357a@github.com> Message-ID: <9R3kGR4n0fw6TRqBMStWzocNVdykrZ4gEBVeGjwkIKk=.551bafdb-dc76-4b21-8018-83daf8016fd8@github.com> On Thu, 28 Jan 2021 12:15:32 GMT, Aleksey Shipilev wrote: > There are two separate counters now: > > f(conc_thread_roots, "Concurrent Stack Processing") \ > f(conc_thread_roots_work, " Threads") \ > SHENANDOAH_PAR_PHASE_DO(conc_thread_roots_work_, " CT: ", f) \ > ...and `_work` counter is unused, and `conc_thread_roots` is used to report worker stats. So the log says ``, where `Thread Roots` should have been mentioned: > > [34.169s][info][gc,stats] Concurrent Stack Processing 11341 us, parallelism: 7.93x > [34.169s][info][gc,stats] Threads 89908 us > [34.169s][info][gc,stats] CT: 89908 us, workers (us): 11231, 11270, 11251, 11252, 11237, 11230, 11214, 11223, > > Fixed log says: > > [99.797s][info][gc,stats] Concurrent Thread Roots 3929 us, parallelism: 7.45x > [99.797s][info][gc,stats] CTR: 29273 us > [99.797s][info][gc,stats] CTR: Thread Roots 29273 us, workers (us): 3652, 3643, 3622, 3623, 3623, 3676, 3606, 3829, > > Also, I believe it should be called "Concurrent Thread Roots", in symmetry with "Concurrent Update Thread Roots" later. Looks good to me. Thank you! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2287 From shade at openjdk.java.net Thu Jan 28 12:44:56 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 28 Jan 2021 12:44:56 GMT Subject: RFR: 8260586: Shenandoah: simplify "Concurrent Weak References" logging Message-ID: Concurrent Weak References always does parallel worker operation. Therefore "Process" counter is redundant, and we might as well make the root counter the per-worker one. This simplifies GC logging. Old log: [95.220s][info][gc,stats] Concurrent Weak References 1709 us [95.220s][info][gc,stats] Process 1588 us, parallelism: 1.30x [95.220s][info][gc,stats] CWRF: 2056 us [95.220s][info][gc,stats] CWRF: Weak References 2056 us, workers (us): 454, 1450, 2, 145, 4, 1, 0, 0, New log: [39.583s][info][gc,stats] Concurrent Weak References 651 us, parallelism: 1.52x [39.583s][info][gc,stats] CWRF: 986 us [39.583s][info][gc,stats] CWRF: Weak References 986 us, workers (us): 183, 29, 145, 627, 1, 0, 0, 0, ------------- Commit messages: - 8260586: Shenandoah: simplify "Concurrent Weak References" logging Changes: https://git.openjdk.java.net/jdk/pull/2288/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2288&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260586 Stats: 6 lines in 3 files changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2288.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2288/head:pull/2288 PR: https://git.openjdk.java.net/jdk/pull/2288 From rkennke at openjdk.java.net Thu Jan 28 12:51:41 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 28 Jan 2021 12:51:41 GMT Subject: RFR: 8260586: Shenandoah: simplify "Concurrent Weak References" logging In-Reply-To: References: Message-ID: <8d4s3167oTU6HMK8oeWjdZ02ViaFRlLVnzO_MXI66u0=.4f63a1dc-70d5-4933-9ab8-bdcd6e7e5d25@github.com> On Thu, 28 Jan 2021 12:36:58 GMT, Aleksey Shipilev wrote: > Concurrent Weak References always does parallel worker operation. Therefore "Process" counter is redundant, and we might as well make the root counter the per-worker one. This simplifies GC logging. > > Old log: > > [95.220s][info][gc,stats] Concurrent Weak References 1709 us > [95.220s][info][gc,stats] Process 1588 us, parallelism: 1.30x > [95.220s][info][gc,stats] CWRF: 2056 us > [95.220s][info][gc,stats] CWRF: Weak References 2056 us, workers (us): 454, 1450, 2, 145, 4, 1, 0, 0, > > New log: > > [39.583s][info][gc,stats] Concurrent Weak References 651 us, parallelism: 1.52x > [39.583s][info][gc,stats] CWRF: 986 us > [39.583s][info][gc,stats] CWRF: Weak References 986 us, workers (us): 183, 29, 145, 627, 1, 0, 0, 0, Looks good! Thanks! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2288 From zgu at openjdk.java.net Thu Jan 28 13:56:42 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 28 Jan 2021 13:56:42 GMT Subject: RFR: 8260584: Shenandoah: simplify "Concurrent Thread Roots" logging In-Reply-To: <_tmnF3EWmNl7yricNI7zUIGGOfcA52knD6hFUGzgTmg=.de301c69-4c25-44e0-a943-a5d778d8357a@github.com> References: <_tmnF3EWmNl7yricNI7zUIGGOfcA52knD6hFUGzgTmg=.de301c69-4c25-44e0-a943-a5d778d8357a@github.com> Message-ID: <5HU-5OewpWehUi6Y6TaJ9_3Gqk5HoNoxsvWGa1oCTlY=.277e1431-1001-4c98-89b8-28fbb91b28fd@github.com> On Thu, 28 Jan 2021 12:15:32 GMT, Aleksey Shipilev wrote: > There are two separate counters now: > > f(conc_thread_roots, "Concurrent Stack Processing") \ > f(conc_thread_roots_work, " Threads") \ > SHENANDOAH_PAR_PHASE_DO(conc_thread_roots_work_, " CT: ", f) \ > ...and `_work` counter is unused, and `conc_thread_roots` is used to report worker stats. So the log says ``, where `Thread Roots` should have been mentioned: > > [34.169s][info][gc,stats] Concurrent Stack Processing 11341 us, parallelism: 7.93x > [34.169s][info][gc,stats] Threads 89908 us > [34.169s][info][gc,stats] CT: 89908 us, workers (us): 11231, 11270, 11251, 11252, 11237, 11230, 11214, 11223, > > Fixed log says: > > [99.797s][info][gc,stats] Concurrent Thread Roots 3929 us, parallelism: 7.45x > [99.797s][info][gc,stats] CTR: 29273 us > [99.797s][info][gc,stats] CTR: Thread Roots 29273 us, workers (us): 3652, 3643, 3622, 3623, 3623, 3676, 3606, 3829, > > Also, I believe it should be called "Concurrent Thread Roots", in symmetry with "Concurrent Update Thread Roots" later. Looks good. ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2287 From shade at openjdk.java.net Thu Jan 28 14:09:52 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 28 Jan 2021 14:09:52 GMT Subject: RFR: 8260591: Shenandoah: improve parallelism for concurrent thread root scans Message-ID: Following JDK-8256298, there are a few minor performance issues with the implementation. First, in the spirit of JDK-8246100, we should be scanning the Java threads the last, as they have the most parallelism. Less parallel, or lightweight roots should be scanned before them to improve overall parallelism. Second, claiming each thread dominates the per-thread processing cost. We should really be doing chunked processing. Motivating example is SPECjvm2008 serial, which has very fast concurrent cycles, and thread root scan speed is important. Before: # Baseline [56.176s][info][gc,stats] Concurrent Mark Roots = 0.308 s (a = 1452 us) (n = 212) (lvls, us = 305, 398, 457, 719, 11216) [56.176s][info][gc,stats] CMR: = 1.236 s (a = 5832 us) (n = 212) (lvls, us = 2676, 3535, 4199, 5391, 54522) [56.176s][info][gc,stats] CMR: Thread Roots = 1.179 s (a = 5563 us) (n = 212) (lvls, us = 2441, 3242, 3945, 5156, 54288) [56.176s][info][gc,stats] CMR: VM Strong Roots = 0.005 s (a = 23 us) (n = 212) (lvls, us = 12, 19, 21, 23, 204) [56.176s][info][gc,stats] CMR: CLDG Roots = 0.052 s (a = 247 us) (n = 212) (lvls, us = 73, 203, 252, 293, 562) ... [56.176s][info][gc,stats] Concurrent Stack Processing = 0.124 s (a = 5149 us) (n = 24) (lvls, us = 535, 607, 885, 6387, 27177) [56.176s][info][gc,stats] Threads = 0.632 s (a = 26345 us) (n = 24) (lvls, us = 6465, 8086, 10742, 39453, 145679) [56.176s][info][gc,stats] CT: = 0.632 s (a = 26345 us) (n = 24) (lvls, us = 6465, 8086, 10742, 39453, 145679) After: [56.010s][info][gc,stats] Concurrent Mark Roots = 0.116 s (a = 587 us) (n = 198) (lvls, us = 312, 371, 400, 502, 4316) [56.010s][info][gc,stats] CMR: = 0.931 s (a = 4703 us) (n = 198) (lvls, us = 2402, 3438, 3770, 4453, 62629) [56.010s][info][gc,stats] CMR: Thread Roots = 0.864 s (a = 4366 us) (n = 198) (lvls, us = 1914, 3125, 3477, 4199, 54075) [56.010s][info][gc,stats] CMR: VM Strong Roots = 0.015 s (a = 76 us) (n = 198) (lvls, us = 20, 31, 35, 38, 4693) [56.010s][info][gc,stats] CMR: CLDG Roots = 0.052 s (a = 261 us) (n = 198) (lvls, us = 61, 172, 256, 299, 3861) ... [56.010s][info][gc,stats] Concurrent Stack Processing = 0.081 s (a = 3671 us) (n = 22) (lvls, us = 457, 537, 770, 3359, 24003) [56.010s][info][gc,stats] Threads = 0.469 s (a = 21309 us) (n = 22) (lvls, us = 6016, 6855, 8711, 18945, 103939) [56.010s][info][gc,stats] CT: = 0.469 s (a = 21309 us) (n = 22) (lvls, us = 6016, 6855, 8711, 18945, 103939) ------------- Commit messages: - 8260591: Shenandoah: improve parallelism for concurrent thread root scans Changes: https://git.openjdk.java.net/jdk/pull/2290/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2290&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260591 Stats: 39 lines in 3 files changed: 20 ins; 7 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/2290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2290/head:pull/2290 PR: https://git.openjdk.java.net/jdk/pull/2290 From zgu at openjdk.java.net Thu Jan 28 14:27:42 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 28 Jan 2021 14:27:42 GMT Subject: RFR: 8260591: Shenandoah: improve parallelism for concurrent thread root scans In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 14:04:07 GMT, Aleksey Shipilev wrote: > Following JDK-8256298, there are a few minor performance issues with the implementation. > > First, in the spirit of JDK-8246100, we should be scanning the Java threads the last, as they have the most parallelism. Less parallel, or lightweight roots should be scanned before them to improve overall parallelism. > > Second, claiming each thread dominates the per-thread processing cost. We should really be doing chunked processing. > > Motivating example is SPECjvm2008 serial, which has very fast concurrent cycles, and thread root scan speed is important. > > Before: > # Baseline > [56.176s][info][gc,stats] Concurrent Mark Roots = 0.308 s (a = 1452 us) (n = 212) (lvls, us = 305, 398, 457, 719, 11216) > [56.176s][info][gc,stats] CMR: = 1.236 s (a = 5832 us) (n = 212) (lvls, us = 2676, 3535, 4199, 5391, 54522) > [56.176s][info][gc,stats] CMR: Thread Roots = 1.179 s (a = 5563 us) (n = 212) (lvls, us = 2441, 3242, 3945, 5156, 54288) > [56.176s][info][gc,stats] CMR: VM Strong Roots = 0.005 s (a = 23 us) (n = 212) (lvls, us = 12, 19, 21, 23, 204) > [56.176s][info][gc,stats] CMR: CLDG Roots = 0.052 s (a = 247 us) (n = 212) (lvls, us = 73, 203, 252, 293, 562) > > ... > [56.176s][info][gc,stats] Concurrent Stack Processing = 0.124 s (a = 5149 us) (n = 24) (lvls, us = 535, 607, 885, 6387, 27177) > [56.176s][info][gc,stats] Threads = 0.632 s (a = 26345 us) (n = 24) (lvls, us = 6465, 8086, 10742, 39453, 145679) > [56.176s][info][gc,stats] CT: = 0.632 s (a = 26345 us) (n = 24) (lvls, us = 6465, 8086, 10742, 39453, 145679) > > After: > [56.010s][info][gc,stats] Concurrent Mark Roots = 0.116 s (a = 587 us) (n = 198) (lvls, us = 312, 371, 400, 502, 4316) > [56.010s][info][gc,stats] CMR: = 0.931 s (a = 4703 us) (n = 198) (lvls, us = 2402, 3438, 3770, 4453, 62629) > [56.010s][info][gc,stats] CMR: Thread Roots = 0.864 s (a = 4366 us) (n = 198) (lvls, us = 1914, 3125, 3477, 4199, 54075) > [56.010s][info][gc,stats] CMR: VM Strong Roots = 0.015 s (a = 76 us) (n = 198) (lvls, us = 20, 31, 35, 38, 4693) > [56.010s][info][gc,stats] CMR: CLDG Roots = 0.052 s (a = 261 us) (n = 198) (lvls, us = 61, 172, 256, 299, 3861) > ... > [56.010s][info][gc,stats] Concurrent Stack Processing = 0.081 s (a = 3671 us) (n = 22) (lvls, us = 457, 537, 770, 3359, 24003) > [56.010s][info][gc,stats] Threads = 0.469 s (a = 21309 us) (n = 22) (lvls, us = 6016, 6855, 8711, 18945, 103939) > [56.010s][info][gc,stats] CT: = 0.469 s (a = 21309 us) (n = 22) (lvls, us = 6016, 6855, 8711, 18945, 103939) Change looks good. I thought fetch_and_add is pretty cheap now, and claiming one thread at a time can balance workload better ... ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2290 From shade at openjdk.java.net Thu Jan 28 14:32:42 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 28 Jan 2021 14:32:42 GMT Subject: RFR: 8260591: Shenandoah: improve parallelism for concurrent thread root scans In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 14:24:35 GMT, Zhengyu Gu wrote: > I thought fetch_and_add is pretty cheap now, and claiming one thread at a time can balance workload better ... Atomics are cheap when uncontended. When per-thread work is small, we run into contended atomic, and get unnecessary slowdowns. Chunking might indeed make balancing less precise, but we might not care as much as contending with many GC worker threads. ------------- PR: https://git.openjdk.java.net/jdk/pull/2290 From rkennke at openjdk.java.net Thu Jan 28 14:45:40 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 28 Jan 2021 14:45:40 GMT Subject: RFR: 8260591: Shenandoah: improve parallelism for concurrent thread root scans In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 14:04:07 GMT, Aleksey Shipilev wrote: > Following JDK-8256298, there are a few minor performance issues with the implementation. > > First, in the spirit of JDK-8246100, we should be scanning the Java threads the last, as they have the most parallelism. Less parallel, or lightweight roots should be scanned before them to improve overall parallelism. > > Second, claiming each thread dominates the per-thread processing cost. We should really be doing chunked processing. > > Motivating example is SPECjvm2008 serial, which has very fast concurrent cycles, and thread root scan speed is important. > > Before: > # Baseline > [56.176s][info][gc,stats] Concurrent Mark Roots = 0.308 s (a = 1452 us) (n = 212) (lvls, us = 305, 398, 457, 719, 11216) > [56.176s][info][gc,stats] CMR: = 1.236 s (a = 5832 us) (n = 212) (lvls, us = 2676, 3535, 4199, 5391, 54522) > [56.176s][info][gc,stats] CMR: Thread Roots = 1.179 s (a = 5563 us) (n = 212) (lvls, us = 2441, 3242, 3945, 5156, 54288) > [56.176s][info][gc,stats] CMR: VM Strong Roots = 0.005 s (a = 23 us) (n = 212) (lvls, us = 12, 19, 21, 23, 204) > [56.176s][info][gc,stats] CMR: CLDG Roots = 0.052 s (a = 247 us) (n = 212) (lvls, us = 73, 203, 252, 293, 562) > > ... > [56.176s][info][gc,stats] Concurrent Stack Processing = 0.124 s (a = 5149 us) (n = 24) (lvls, us = 535, 607, 885, 6387, 27177) > [56.176s][info][gc,stats] Threads = 0.632 s (a = 26345 us) (n = 24) (lvls, us = 6465, 8086, 10742, 39453, 145679) > [56.176s][info][gc,stats] CT: = 0.632 s (a = 26345 us) (n = 24) (lvls, us = 6465, 8086, 10742, 39453, 145679) > > After: > [56.010s][info][gc,stats] Concurrent Mark Roots = 0.116 s (a = 587 us) (n = 198) (lvls, us = 312, 371, 400, 502, 4316) > [56.010s][info][gc,stats] CMR: = 0.931 s (a = 4703 us) (n = 198) (lvls, us = 2402, 3438, 3770, 4453, 62629) > [56.010s][info][gc,stats] CMR: Thread Roots = 0.864 s (a = 4366 us) (n = 198) (lvls, us = 1914, 3125, 3477, 4199, 54075) > [56.010s][info][gc,stats] CMR: VM Strong Roots = 0.015 s (a = 76 us) (n = 198) (lvls, us = 20, 31, 35, 38, 4693) > [56.010s][info][gc,stats] CMR: CLDG Roots = 0.052 s (a = 261 us) (n = 198) (lvls, us = 61, 172, 256, 299, 3861) > ... > [56.010s][info][gc,stats] Concurrent Stack Processing = 0.081 s (a = 3671 us) (n = 22) (lvls, us = 457, 537, 770, 3359, 24003) > [56.010s][info][gc,stats] Threads = 0.469 s (a = 21309 us) (n = 22) (lvls, us = 6016, 6855, 8711, 18945, 103939) > [56.010s][info][gc,stats] CT: = 0.469 s (a = 21309 us) (n = 22) (lvls, us = 6016, 6855, 8711, 18945, 103939) It's ok by me. I wonder if we could collapse all concurrent-FOO tasks after final-mark into a single task and benefit from even better parallelism there? ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2290 From shade at openjdk.java.net Thu Jan 28 16:34:41 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 28 Jan 2021 16:34:41 GMT Subject: Integrated: 8260584: Shenandoah: simplify "Concurrent Thread Roots" logging In-Reply-To: <_tmnF3EWmNl7yricNI7zUIGGOfcA52knD6hFUGzgTmg=.de301c69-4c25-44e0-a943-a5d778d8357a@github.com> References: <_tmnF3EWmNl7yricNI7zUIGGOfcA52knD6hFUGzgTmg=.de301c69-4c25-44e0-a943-a5d778d8357a@github.com> Message-ID: On Thu, 28 Jan 2021 12:15:32 GMT, Aleksey Shipilev wrote: > There are two separate counters now: > > f(conc_thread_roots, "Concurrent Stack Processing") \ > f(conc_thread_roots_work, " Threads") \ > SHENANDOAH_PAR_PHASE_DO(conc_thread_roots_work_, " CT: ", f) \ > ...and `_work` counter is unused, and `conc_thread_roots` is used to report worker stats. So the log says ``, where `Thread Roots` should have been mentioned: > > [34.169s][info][gc,stats] Concurrent Stack Processing 11341 us, parallelism: 7.93x > [34.169s][info][gc,stats] Threads 89908 us > [34.169s][info][gc,stats] CT: 89908 us, workers (us): 11231, 11270, 11251, 11252, 11237, 11230, 11214, 11223, > > Fixed log says: > > [99.797s][info][gc,stats] Concurrent Thread Roots 3929 us, parallelism: 7.45x > [99.797s][info][gc,stats] CTR: 29273 us > [99.797s][info][gc,stats] CTR: Thread Roots 29273 us, workers (us): 3652, 3643, 3622, 3623, 3623, 3676, 3606, 3829, > > Also, I believe it should be called "Concurrent Thread Roots", in symmetry with "Concurrent Update Thread Roots" later. This pull request has now been integrated. Changeset: 1de3c554 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/1de3c554 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod 8260584: Shenandoah: simplify "Concurrent Thread Roots" logging Reviewed-by: rkennke, zgu ------------- PR: https://git.openjdk.java.net/jdk/pull/2287 From shade at openjdk.java.net Thu Jan 28 17:05:00 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 28 Jan 2021 17:05:00 GMT Subject: RFR: 8260586: Shenandoah: simplify "Concurrent Weak References" logging [v2] In-Reply-To: References: Message-ID: > Concurrent Weak References always does parallel worker operation. Therefore "Process" counter is redundant, and we might as well make the root counter the per-worker one. This simplifies GC logging. > > Old log: > > [95.220s][info][gc,stats] Concurrent Weak References 1709 us > [95.220s][info][gc,stats] Process 1588 us, parallelism: 1.30x > [95.220s][info][gc,stats] CWRF: 2056 us > [95.220s][info][gc,stats] CWRF: Weak References 2056 us, workers (us): 454, 1450, 2, 145, 4, 1, 0, 0, > > New log: > > [39.583s][info][gc,stats] Concurrent Weak References 651 us, parallelism: 1.52x > [39.583s][info][gc,stats] CWRF: 986 us > [39.583s][info][gc,stats] CWRF: Weak References 986 us, workers (us): 183, 29, 145, 627, 1, 0, 0, 0, Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into JDK-8260586-sh-log-cwr - 8260586: Shenandoah: simplify "Concurrent Weak References" logging ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2288/files - new: https://git.openjdk.java.net/jdk/pull/2288/files/8b9bf2e1..a493df7c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2288&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2288&range=00-01 Stats: 426 lines in 28 files changed: 232 ins; 64 del; 130 mod Patch: https://git.openjdk.java.net/jdk/pull/2288.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2288/head:pull/2288 PR: https://git.openjdk.java.net/jdk/pull/2288 From zgu at openjdk.java.net Thu Jan 28 17:29:44 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 28 Jan 2021 17:29:44 GMT Subject: RFR: 8260586: Shenandoah: simplify "Concurrent Weak References" logging [v2] In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 17:05:00 GMT, Aleksey Shipilev wrote: >> Concurrent Weak References always does parallel worker operation. Therefore "Process" counter is redundant, and we might as well make the root counter the per-worker one. This simplifies GC logging. >> >> Old log: >> >> [95.220s][info][gc,stats] Concurrent Weak References 1709 us >> [95.220s][info][gc,stats] Process 1588 us, parallelism: 1.30x >> [95.220s][info][gc,stats] CWRF: 2056 us >> [95.220s][info][gc,stats] CWRF: Weak References 2056 us, workers (us): 454, 1450, 2, 145, 4, 1, 0, 0, >> >> New log: >> >> [39.583s][info][gc,stats] Concurrent Weak References 651 us, parallelism: 1.52x >> [39.583s][info][gc,stats] CWRF: 986 us >> [39.583s][info][gc,stats] CWRF: Weak References 986 us, workers (us): 183, 29, 145, 627, 1, 0, 0, 0, > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into JDK-8260586-sh-log-cwr > - 8260586: Shenandoah: simplify "Concurrent Weak References" logging Looks good. ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2288 From zgu at openjdk.java.net Thu Jan 28 17:40:52 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 28 Jan 2021 17:40:52 GMT Subject: RFR: 8259404: Shenandoah: Fix time tracking in parallel_cleaning Message-ID: Please review this patch fixes timing tracking for parallel cleaning. Before: [9.844s][info][gc,stats] System Purge = 0.000 s (a = 76 us) (n = 1) (lvls, us = 76, 76, 76, 76, 76) **_<<=== looks wrong_** [9.844s][info][gc,stats] Unload Classes = 0.001 s (a = 541 us) (n = 1) (lvls, us = 541, 541, 541, 541, 541) [9.844s][info][gc,stats] Weak Roots = 0.000 s (a = 75 us) (n = 1) (lvls, us = 75, 75, 75, 75, 75) [9.844s][info][gc,stats] CLDG = 0.000 s (a = 0 us) (n = 1) (lvls, us = 0, 0, 0, 0, 0) After: [9.936s][info][gc,stats] System Purge = 0.001 s (a = 611 us) (n = 1) (lvls, us = 609, 609, 609, 609, 611) [9.936s][info][gc,stats] Unload Classes = 0.000 s (a = 475 us) (n = 1) (lvls, us = 475, 475, 475, 475, 475) [9.936s][info][gc,stats] DCU: = 0.000 s (a = 162 us) (n = 1) (lvls, us = 160, 160, 160, 160, 162) [9.936s][info][gc,stats] DCU: Code Cache Roots = 0.000 s (a = 162 us) (n = 1) (lvls, us = 160, 160, 160, 160, 162) [9.936s][info][gc,stats] Weak Roots = 0.000 s (a = 105 us) (n = 1) (lvls, us = 105, 105, 105, 105, 105) [9.936s][info][gc,stats] DWR: = 0.000 s (a = 210 us) (n = 1) (lvls, us = 209, 209, 209, 209, 210) [9.936s][info][gc,stats] DWR: VM Weak Roots = 0.000 s (a = 210 us) (n = 1) (lvls, us = 209, 209, 209, 209 ------------- Commit messages: - Merge master - Fix indentation and removed unused phase - Merge - Update - Fix indentations - init update - cleanup - JDK-8259377: init update Changes: https://git.openjdk.java.net/jdk/pull/2073/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2073&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259404 Stats: 53 lines in 5 files changed: 19 ins; 12 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/2073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2073/head:pull/2073 PR: https://git.openjdk.java.net/jdk/pull/2073 From shade at openjdk.java.net Thu Jan 28 18:10:45 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 28 Jan 2021 18:10:45 GMT Subject: RFR: 8259404: Shenandoah: Fix time tracking in parallel_cleaning In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 01:39:02 GMT, Zhengyu Gu wrote: > Please review this patch fixes timing tracking for parallel cleaning. > > Before: > `[9.844s][info][gc,stats] System Purge = 0.000 s (a = 76 us) (n = 1) (lvls, us = 76, 76, 76, 76, 76)` **<<== looks wrong** > `[9.844s][info][gc,stats] Unload Classes = 0.001 s (a = 541 us) (n = 1) (lvls, us = 541, 541, 541, 541, 541)` > `[9.844s][info][gc,stats] Weak Roots = 0.000 s (a = 75 us) (n = 1) (lvls, us = 75, 75, 75, 75, 75)` > `[9.844s][info][gc,stats] CLDG = 0.000 s (a = 0 us) (n = 1) (lvls, us = 0, 0, 0, 0, 0)` > After: > `[9.936s][info][gc,stats] System Purge = 0.001 s (a = 611 us) (n = 1) (lvls, us = 609, 609, 609, 609, 611)` > `[9.936s][info][gc,stats] Unload Classes = 0.000 s (a = 475 us) (n = 1) (lvls, us = 475, 475, 475, 475, 475)` > `[9.936s][info][gc,stats] DCU: = 0.000 s (a = 162 us) (n = 1) (lvls, us = 160, 160, 160, 160, 162)` > `[9.936s][info][gc,stats] DCU: Code Cache Roots = 0.000 s (a = 162 us) (n = 1) (lvls, us = 160, 160, 160, 160, 162)` > `[9.936s][info][gc,stats] Weak Roots = 0.000 s (a = 105 us) (n = 1) (lvls, us = 105, 105, 105, 105, 105)` > `[9.936s][info][gc,stats] DWR: = 0.000 s (a = 210 us) (n = 1) (lvls, us = 209, 209, 209, 209, 210)` > `[9.936s][info][gc,stats] DWR: VM Weak Roots = 0.000 s (a = 210 us) (n = 1) (lvls, us = 209, 209, 209, 209)` It is okay, but I have suggestions. src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1795: > 1793: // Unload classes and purge SystemDictionary. > 1794: { > 1795: ShenandoahPhaseTimings::Phase p = full_gc ? Please name the local variable `phase`. `p` is usually a "location" around GC code. src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1854: > 1852: assert(SafepointSynchronize::is_at_safepoint(), "Must be at a safepoint"); > 1853: assert(is_stw_gc_in_progress(), "Only for Degenerated and Full GC"); > 1854: ShenandoahGCPhase root_phase(full_gc ? Name it `phase`? src/hotspot/share/gc/shenandoah/shenandoahParallelCleaning.cpp line 49: > 47: { > 48: ShenandoahWorkerTimingsTracker x(_phase, ShenandoahPhaseTimings::CodeCacheRoots, worker_id); > 49: _code_cache_task.work(worker_id); This does not look like "normal" code cache root operation, though, right? Consider adding another type to `SHENANDOAH_PAR_PHASE_DO` instead? I.e. `CodeCacheUnload`? src/hotspot/share/gc/shenandoah/shenandoahParallelCleaning.cpp line 56: > 54: if (_unloading_occurred) { > 55: ShenandoahWorkerTimingsTracker x(_phase, ShenandoahPhaseTimings::CLDGRoots, worker_id); > 56: _klass_cleaning_task.work(); Same thing, maybe new type of `SHENANDOAH_PAR_PHASE_DO`? src/hotspot/share/gc/shenandoah/shenandoahParallelCleaning.inline.hpp line 60: > 58: _weak_processing_task.work(worker_id, _is_alive, _keep_alive); > 59: } > 60: _dedup_roots.oops_do(_is_alive, _keep_alive, worker_id); This might need `ShenadoahWorkerTimingsTracker(... ShenandoahPhaseTimings::StringDedupTableRoots, ...)`? ------------- Changes requested by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2073 From shade at openjdk.java.net Thu Jan 28 19:07:42 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 28 Jan 2021 19:07:42 GMT Subject: Integrated: 8260586: Shenandoah: simplify "Concurrent Weak References" logging In-Reply-To: References: Message-ID: <2C0ix6hcOaQ7AitU9NcCG_hKqHfLvE-95s5XR_4YWJI=.0b34752f-ee2a-4f22-bf6b-7e5198a27e8e@github.com> On Thu, 28 Jan 2021 12:36:58 GMT, Aleksey Shipilev wrote: > Concurrent Weak References always does parallel worker operation. Therefore "Process" counter is redundant, and we might as well make the root counter the per-worker one. This simplifies GC logging. > > Old log: > > [95.220s][info][gc,stats] Concurrent Weak References 1709 us > [95.220s][info][gc,stats] Process 1588 us, parallelism: 1.30x > [95.220s][info][gc,stats] CWRF: 2056 us > [95.220s][info][gc,stats] CWRF: Weak References 2056 us, workers (us): 454, 1450, 2, 145, 4, 1, 0, 0, > > New log: > > [39.583s][info][gc,stats] Concurrent Weak References 651 us, parallelism: 1.52x > [39.583s][info][gc,stats] CWRF: 986 us > [39.583s][info][gc,stats] CWRF: Weak References 986 us, workers (us): 183, 29, 145, 627, 1, 0, 0, 0, This pull request has now been integrated. Changeset: 71128cf4 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/71128cf4 Stats: 6 lines in 3 files changed: 0 ins; 2 del; 4 mod 8260586: Shenandoah: simplify "Concurrent Weak References" logging Reviewed-by: rkennke, zgu ------------- PR: https://git.openjdk.java.net/jdk/pull/2288 From zgu at openjdk.java.net Thu Jan 28 19:12:54 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 28 Jan 2021 19:12:54 GMT Subject: RFR: 8259404: Shenandoah: Fix time tracking in parallel_cleaning [v2] In-Reply-To: References: Message-ID: > Please review this patch fixes timing tracking for parallel cleaning. > > Before: > `[9.844s][info][gc,stats] System Purge = 0.000 s (a = 76 us) (n = 1) (lvls, us = 76, 76, 76, 76, 76)` **<<== looks wrong** > `[9.844s][info][gc,stats] Unload Classes = 0.001 s (a = 541 us) (n = 1) (lvls, us = 541, 541, 541, 541, 541)` > `[9.844s][info][gc,stats] Weak Roots = 0.000 s (a = 75 us) (n = 1) (lvls, us = 75, 75, 75, 75, 75)` > `[9.844s][info][gc,stats] CLDG = 0.000 s (a = 0 us) (n = 1) (lvls, us = 0, 0, 0, 0, 0)` > After: > `[9.936s][info][gc,stats] System Purge = 0.001 s (a = 611 us) (n = 1) (lvls, us = 609, 609, 609, 609, 611)` > `[9.936s][info][gc,stats] Unload Classes = 0.000 s (a = 475 us) (n = 1) (lvls, us = 475, 475, 475, 475, 475)` > `[9.936s][info][gc,stats] DCU: = 0.000 s (a = 162 us) (n = 1) (lvls, us = 160, 160, 160, 160, 162)` > `[9.936s][info][gc,stats] DCU: Code Cache Roots = 0.000 s (a = 162 us) (n = 1) (lvls, us = 160, 160, 160, 160, 162)` > `[9.936s][info][gc,stats] Weak Roots = 0.000 s (a = 105 us) (n = 1) (lvls, us = 105, 105, 105, 105, 105)` > `[9.936s][info][gc,stats] DWR: = 0.000 s (a = 210 us) (n = 1) (lvls, us = 209, 209, 209, 209, 210)` > `[9.936s][info][gc,stats] DWR: VM Weak Roots = 0.000 s (a = 210 us) (n = 1) (lvls, us = 209, 209, 209, 209)` Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Aleksey's comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2073/files - new: https://git.openjdk.java.net/jdk/pull/2073/files/3ae33066..33be84c9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2073&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2073&range=00-01 Stats: 21 lines in 3 files changed: 6 ins; 4 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/2073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2073/head:pull/2073 PR: https://git.openjdk.java.net/jdk/pull/2073 From shade at openjdk.java.net Thu Jan 28 19:12:54 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 28 Jan 2021 19:12:54 GMT Subject: RFR: 8259404: Shenandoah: Fix time tracking in parallel_cleaning [v2] In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 19:09:49 GMT, Zhengyu Gu wrote: >> Please review this patch fixes timing tracking for parallel cleaning. >> >> Before: >> `[9.844s][info][gc,stats] System Purge = 0.000 s (a = 76 us) (n = 1) (lvls, us = 76, 76, 76, 76, 76)` **<<== looks wrong** >> `[9.844s][info][gc,stats] Unload Classes = 0.001 s (a = 541 us) (n = 1) (lvls, us = 541, 541, 541, 541, 541)` >> `[9.844s][info][gc,stats] Weak Roots = 0.000 s (a = 75 us) (n = 1) (lvls, us = 75, 75, 75, 75, 75)` >> `[9.844s][info][gc,stats] CLDG = 0.000 s (a = 0 us) (n = 1) (lvls, us = 0, 0, 0, 0, 0)` >> After: >> `[9.936s][info][gc,stats] System Purge = 0.001 s (a = 611 us) (n = 1) (lvls, us = 609, 609, 609, 609, 611)` >> `[9.936s][info][gc,stats] Unload Classes = 0.000 s (a = 475 us) (n = 1) (lvls, us = 475, 475, 475, 475, 475)` >> `[9.936s][info][gc,stats] DCU: = 0.000 s (a = 162 us) (n = 1) (lvls, us = 160, 160, 160, 160, 162)` >> `[9.936s][info][gc,stats] DCU: Code Cache Roots = 0.000 s (a = 162 us) (n = 1) (lvls, us = 160, 160, 160, 160, 162)` >> `[9.936s][info][gc,stats] Weak Roots = 0.000 s (a = 105 us) (n = 1) (lvls, us = 105, 105, 105, 105, 105)` >> `[9.936s][info][gc,stats] DWR: = 0.000 s (a = 210 us) (n = 1) (lvls, us = 209, 209, 209, 209, 210)` >> `[9.936s][info][gc,stats] DWR: VM Weak Roots = 0.000 s (a = 210 us) (n = 1) (lvls, us = 209, 209, 209, 209)` > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Aleksey's comments Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2073 From iveresov at openjdk.java.net Thu Jan 28 20:53:49 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Thu, 28 Jan 2021 20:53:49 GMT Subject: Integrated: 8251462: Simplify compilation policy In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 18:43:51 GMT, Igor Veresov wrote: > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. > > Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! This pull request has now been integrated. Changeset: 15196325 Author: Igor Veresov URL: https://git.openjdk.java.net/jdk/commit/15196325 Stats: 5314 lines in 98 files changed: 1519 ins; 2994 del; 801 mod 8251462: Simplify compilation policy Reviewed-by: cjplummer, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iklam at openjdk.java.net Thu Jan 28 21:07:57 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 28 Jan 2021 21:07:57 GMT Subject: RFR: 8260471: Change SystemDictionary::X_klass calls to vmClasses::X_klass Message-ID: This is the second step of https://github.com/openjdk/jdk/pull/2246 (8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp). These are mostly boiler-plate changes done by scripts. [1] Change calls like SystemDictionary::Object_klass() SystemDictionary::Throwable_klass_is_loaded() SystemDictionary::box_klass_type() to vmClasses::Object_klass() vmClasses::Throwable_klass_is_loaded() vmClasses::box_klass_type() [2] Remove unnecessary inclusion of systemDictionary.hpp (replace with vmClasses.hpp if necessary). In some cases, I have to add signature.hpp to some files, which only indirectly included signature.hpp through systemDictionary.hpp. [3] In the previous PR, I incorrectly used the enum name `VMClassID`. This PR changes it to `vmClassID` to match the existing use of `vmSymbolID` and `vmIntrinsicID`. Due to the refactoring of these two PRs, the number of HotSpot .o files that include systemDictionary.hpp decreases from 491 to 91. HotSpot build time is reduced by about 2% Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. ------------- Commit messages: - 8260471: Change SystemDictionary::xxx_klass() calls to vmClasses::xxx_klass() Changes: https://git.openjdk.java.net/jdk/pull/2301/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2301&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260471 Stats: 691 lines in 185 files changed: 85 ins; 64 del; 542 mod Patch: https://git.openjdk.java.net/jdk/pull/2301.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2301/head:pull/2301 PR: https://git.openjdk.java.net/jdk/pull/2301 From iklam at openjdk.java.net Thu Jan 28 21:07:57 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 28 Jan 2021 21:07:57 GMT Subject: RFR: 8260471: Change SystemDictionary::X_klass calls to vmClasses::X_klass In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 21:00:04 GMT, Ioi Lam wrote: > This is the second step of https://github.com/openjdk/jdk/pull/2246 (8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp). These are mostly boiler-plate changes done by scripts. > > [1] Change calls like > > SystemDictionary::Object_klass() > SystemDictionary::Throwable_klass_is_loaded() > SystemDictionary::box_klass_type() > > to > > vmClasses::Object_klass() > vmClasses::Throwable_klass_is_loaded() > vmClasses::box_klass_type() > > [2] Remove unnecessary inclusion of systemDictionary.hpp (replace with vmClasses.hpp if necessary). In some cases, I have to add signature.hpp to some files, which only indirectly included signature.hpp through systemDictionary.hpp. > > [3] In the previous PR, I incorrectly used the enum name `VMClassID`. This PR changes it to `vmClassID` to match the existing use of `vmSymbolID` and `vmIntrinsicID`. > > Due to the refactoring of these two PRs, the number of HotSpot .o files that include systemDictionary.hpp decreases from 491 to 91. HotSpot build time is reduced by about 2% > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. To make reviewing the 185 files a little easier, I haven't changed the copyright dates yet. I'll do that before the final integration. ------------- PR: https://git.openjdk.java.net/jdk/pull/2301 From shade at openjdk.java.net Fri Jan 29 08:26:51 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 29 Jan 2021 08:26:51 GMT Subject: [jdk16] RFR: 8260632: Build failures after JDK-8253353 Message-ID: [JDK-8253353](https://bugs.openjdk.java.net/browse/JDK-8253353) changed the field to `uint16_t`, and now `shenadoahSupport.cpp` code runs into ambiguity choosing between `uint8_t` and `uint16_t` when instantiating `MAX2` macro: max_depth = MAX2(max_depth, lpt->_nest); ^ In file included from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/metaprogramming/primitiveConversions.hpp:30:0, from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/oops/oopHandle.hpp:28, from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/classfile/systemDictionary.hpp:28, from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/classfile/javaClasses.hpp:28, from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp:27: ------------- Commit messages: - 8260632: Build failures after JDK-8253353 Changes: https://git.openjdk.java.net/jdk16/pull/138/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=138&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260632 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/138.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/138/head:pull/138 PR: https://git.openjdk.java.net/jdk16/pull/138 From stuefe at openjdk.java.net Fri Jan 29 08:38:42 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 29 Jan 2021 08:38:42 GMT Subject: [jdk16] RFR: 8260632: Build failures after JDK-8253353 In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 08:20:10 GMT, Aleksey Shipilev wrote: > [JDK-8253353](https://bugs.openjdk.java.net/browse/JDK-8253353) changed the field to `uint16_t`, and now `shenadoahSupport.cpp` code runs into ambiguity choosing between `uint8_t` and `uint16_t` when instantiating `MAX2` macro: > > > max_depth = MAX2(max_depth, lpt->_nest); > ^ > In file included from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/metaprogramming/primitiveConversions.hpp:30:0, > from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/oops/oopHandle.hpp:28, > from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/classfile/systemDictionary.hpp:28, > from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/classfile/javaClasses.hpp:28, > from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp:27: Seems fine and trivial to me. ..Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/138 From thartmann at openjdk.java.net Fri Jan 29 08:53:41 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 29 Jan 2021 08:53:41 GMT Subject: [jdk16] RFR: 8260632: Build failures after JDK-8253353 In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 08:20:10 GMT, Aleksey Shipilev wrote: > [JDK-8253353](https://bugs.openjdk.java.net/browse/JDK-8253353) changed the field to `uint16_t`, and now `shenadoahSupport.cpp` code runs into ambiguity choosing between `uint8_t` and `uint16_t` when instantiating `MAX2` macro: > > > max_depth = MAX2(max_depth, lpt->_nest); > ^ > In file included from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/metaprogramming/primitiveConversions.hpp:30:0, > from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/oops/oopHandle.hpp:28, > from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/classfile/systemDictionary.hpp:28, > from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/classfile/javaClasses.hpp:28, > from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp:27: Marked as reviewed by thartmann (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/138 From zgu at openjdk.java.net Fri Jan 29 13:04:40 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 29 Jan 2021 13:04:40 GMT Subject: Integrated: 8259404: Shenandoah: Fix time tracking in parallel_cleaning In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 01:39:02 GMT, Zhengyu Gu wrote: > Please review this patch fixes timing tracking for parallel cleaning. > > Before: > `[9.844s][info][gc,stats] System Purge = 0.000 s (a = 76 us) (n = 1) (lvls, us = 76, 76, 76, 76, 76)` **<<== looks wrong** > `[9.844s][info][gc,stats] Unload Classes = 0.001 s (a = 541 us) (n = 1) (lvls, us = 541, 541, 541, 541, 541)` > `[9.844s][info][gc,stats] Weak Roots = 0.000 s (a = 75 us) (n = 1) (lvls, us = 75, 75, 75, 75, 75)` > `[9.844s][info][gc,stats] CLDG = 0.000 s (a = 0 us) (n = 1) (lvls, us = 0, 0, 0, 0, 0)` > After: > `[9.936s][info][gc,stats] System Purge = 0.001 s (a = 611 us) (n = 1) (lvls, us = 609, 609, 609, 609, 611)` > `[9.936s][info][gc,stats] Unload Classes = 0.000 s (a = 475 us) (n = 1) (lvls, us = 475, 475, 475, 475, 475)` > `[9.936s][info][gc,stats] DCU: = 0.000 s (a = 162 us) (n = 1) (lvls, us = 160, 160, 160, 160, 162)` > `[9.936s][info][gc,stats] DCU: Code Cache Roots = 0.000 s (a = 162 us) (n = 1) (lvls, us = 160, 160, 160, 160, 162)` > `[9.936s][info][gc,stats] Weak Roots = 0.000 s (a = 105 us) (n = 1) (lvls, us = 105, 105, 105, 105, 105)` > `[9.936s][info][gc,stats] DWR: = 0.000 s (a = 210 us) (n = 1) (lvls, us = 209, 209, 209, 209, 210)` > `[9.936s][info][gc,stats] DWR: VM Weak Roots = 0.000 s (a = 210 us) (n = 1) (lvls, us = 209, 209, 209, 209)` This pull request has now been integrated. Changeset: a5fb5173 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/a5fb5173 Stats: 63 lines in 5 files changed: 25 ins; 16 del; 22 mod 8259404: Shenandoah: Fix time tracking in parallel_cleaning Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/2073 From rkennke at openjdk.java.net Fri Jan 29 13:42:41 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 29 Jan 2021 13:42:41 GMT Subject: RFR: 8255837: Shenandoah: Remove ShenandoahConcurrentRoots class In-Reply-To: <0qG_GQeV5H4SJ-at5sZYqb9DfQXxB8iTKqu5Lrq9cX0=.dc182daf-dd84-453c-9f3b-e9cf81acfc02@github.com> References: <0qG_GQeV5H4SJ-at5sZYqb9DfQXxB8iTKqu5Lrq9cX0=.dc182daf-dd84-453c-9f3b-e9cf81acfc02@github.com> Message-ID: <9MAE7v82bOSMMGJ_i-JoxH_jKTHtFYFrms-1BrrrBkQ=.dd609312-c1ba-4d27-a4c2-e490bf0584d8@github.com> On Wed, 27 Jan 2021 14:14:50 GMT, Zhengyu Gu wrote: > The class was introduced for 2 purposes: > 1) a platform supports concurrent class unloading (e.g. the platform supports nmethod_entry_barrier) > 2) should perform concurrent class unloading for particular gc cycle (e.g. STW vs. concurrent GC) > > Now, concurrent class unloading is supported on all Shenandoah supported platforms. Furthermore, STW and concurrent GC are isolated (JDK-8255765), the class not only becomes superfluous, but also looks weird, e.g. > > `bool do_nmethods = heap->unload_classes() && !ShenandoahConcurrentRoots::can_do_concurrent_class_unloading(); ` > > Test: > - [x] hotspot_gc_shenandoah Linux x86_64 and x86_32 > - [x] nightly Looks good to me! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2262 From zgu at openjdk.java.net Fri Jan 29 14:24:43 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 29 Jan 2021 14:24:43 GMT Subject: Integrated: 8255837: Shenandoah: Remove ShenandoahConcurrentRoots class In-Reply-To: <0qG_GQeV5H4SJ-at5sZYqb9DfQXxB8iTKqu5Lrq9cX0=.dc182daf-dd84-453c-9f3b-e9cf81acfc02@github.com> References: <0qG_GQeV5H4SJ-at5sZYqb9DfQXxB8iTKqu5Lrq9cX0=.dc182daf-dd84-453c-9f3b-e9cf81acfc02@github.com> Message-ID: On Wed, 27 Jan 2021 14:14:50 GMT, Zhengyu Gu wrote: > The class was introduced for 2 purposes: > 1) a platform supports concurrent class unloading (e.g. the platform supports nmethod_entry_barrier) > 2) should perform concurrent class unloading for particular gc cycle (e.g. STW vs. concurrent GC) > > Now, concurrent class unloading is supported on all Shenandoah supported platforms. Furthermore, STW and concurrent GC are isolated (JDK-8255765), the class not only becomes superfluous, but also looks weird, e.g. > > `bool do_nmethods = heap->unload_classes() && !ShenandoahConcurrentRoots::can_do_concurrent_class_unloading(); ` > > Test: > - [x] hotspot_gc_shenandoah Linux x86_64 and x86_32 > - [x] nightly This pull request has now been integrated. Changeset: 22bfa5b0 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/22bfa5b0 Stats: 165 lines in 16 files changed: 0 ins; 124 del; 41 mod 8255837: Shenandoah: Remove ShenandoahConcurrentRoots class Reviewed-by: rkennke ------------- PR: https://git.openjdk.java.net/jdk/pull/2262 From iklam at openjdk.java.net Fri Jan 29 14:26:03 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 29 Jan 2021 14:26:03 GMT Subject: RFR: 8260471: Change SystemDictionary::X_klass calls to vmClasses::X_klass [v2] In-Reply-To: References: Message-ID: > This is the second step of https://github.com/openjdk/jdk/pull/2246 (8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp). These are mostly boiler-plate changes done by scripts. > > [1] Change calls like > > SystemDictionary::Object_klass() > SystemDictionary::Throwable_klass_is_loaded() > SystemDictionary::box_klass_type() > > to > > vmClasses::Object_klass() > vmClasses::Throwable_klass_is_loaded() > vmClasses::box_klass_type() > > [2] Remove unnecessary inclusion of systemDictionary.hpp (replace with vmClasses.hpp if necessary). In some cases, I have to add signature.hpp to some files, which only indirectly included signature.hpp through systemDictionary.hpp. > > [3] In the previous PR, I incorrectly used the enum name `VMClassID`. This PR changes it to `vmClassID` to match the existing use of `vmSymbolID` and `vmIntrinsicID`. > > Due to the refactoring of these two PRs, the number of HotSpot .o files that include systemDictionary.hpp decreases from 491 to 91. HotSpot build time is reduced by about 2% > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. > > Review Notes: if you don't want to scroll through 185 files, you may want to try: > > curl https://github.com/openjdk/jdk/compare/1de3c554477497d1ceee573180940e8d38c364ee...e2f77252c8b3edd4d0071cfc014290568a16de9d.diff | \ > grep -v '^[+-][+-][+-]' | grep '^[+-]' Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: added missing #include systemDictionary.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2301/files - new: https://git.openjdk.java.net/jdk/pull/2301/files/e2f77252..e1a09411 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2301&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2301&range=00-01 Stats: 8 lines in 8 files changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2301.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2301/head:pull/2301 PR: https://git.openjdk.java.net/jdk/pull/2301 From shade at openjdk.java.net Fri Jan 29 14:34:57 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 29 Jan 2021 14:34:57 GMT Subject: RFR: 8260309: Shenandoah: Clean up ShenandoahBarrierSet In-Reply-To: <5t_ZDBfj_4BxoJLoWh3R0r6OCh2Q0wc-DNJntvfhW1Q=.925a092e-c1d3-41df-b216-1cbb0b936959@github.com> References: <5t_ZDBfj_4BxoJLoWh3R0r6OCh2Q0wc-DNJntvfhW1Q=.925a092e-c1d3-41df-b216-1cbb0b936959@github.com> Message-ID: On Fri, 22 Jan 2021 19:03:14 GMT, Roman Kennke wrote: > We collected some cruft in ShenandoahBarrierSet. Time to clean it up. > > This fixes/removes a number of includes, fixes some comments and it also removes is_a() and is_aligned() which look like leftovers/requirements from earlier incarnations of the superclass BarrierSet. Using the override keyword would be useful for such situations (btw, are we ok to start using override, nullptr, auto etc in Shenandoah, or do we want to keep it C++ for backporting ease?) > > One thing I was not sure about is the ShenandoahHeap* _heap field. Making it const will likely help the compiler avoid repeated access (e.g. in a number of perf-critical paths like the LRB impl). However, maybe we should get rid of the field altogether and make it explicitely using ShenandoahHeap::heap() and avoid repeated access instead of helping the compiler and hoping for the best? > > Testing: > - [x] hotspot_gc_shenandoah release, fastdebug What is up with this PR? There are no recorded changes, and tests are failing ;) ------------- PR: https://git.openjdk.java.net/jdk/pull/2202 From rkennke at openjdk.java.net Fri Jan 29 14:34:57 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 29 Jan 2021 14:34:57 GMT Subject: RFR: 8260309: Shenandoah: Clean up ShenandoahBarrierSet Message-ID: <5t_ZDBfj_4BxoJLoWh3R0r6OCh2Q0wc-DNJntvfhW1Q=.925a092e-c1d3-41df-b216-1cbb0b936959@github.com> We collected some cruft in ShenandoahBarrierSet. Time to clean it up. This fixes/removes a number of includes, fixes some comments and it also removes is_a() and is_aligned() which look like leftovers/requirements from earlier incarnations of the superclass BarrierSet. Using the override keyword would be useful for such situations (btw, are we ok to start using override, nullptr, auto etc in Shenandoah, or do we want to keep it C++ for backporting ease?) One thing I was not sure about is the ShenandoahHeap* _heap field. Making it const will likely help the compiler avoid repeated access (e.g. in a number of perf-critical paths like the LRB impl). However, maybe we should get rid of the field altogether and make it explicitely using ShenandoahHeap::heap() and avoid repeated access instead of helping the compiler and hoping for the best? Testing: - [x] hotspot_gc_shenandoah release, fastdebug ------------- Commit messages: - 8260309: Shenandoah: Clean up ShenandoahBarrierSet Changes: https://git.openjdk.java.net/jdk/pull/2202/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2202&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260309 Stats: 32 lines in 6 files changed: 3 ins; 21 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/2202.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2202/head:pull/2202 PR: https://git.openjdk.java.net/jdk/pull/2202 From rkennke at openjdk.java.net Fri Jan 29 14:34:57 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 29 Jan 2021 14:34:57 GMT Subject: RFR: 8260309: Shenandoah: Clean up ShenandoahBarrierSet In-Reply-To: References: <5t_ZDBfj_4BxoJLoWh3R0r6OCh2Q0wc-DNJntvfhW1Q=.925a092e-c1d3-41df-b216-1cbb0b936959@github.com> Message-ID: On Fri, 29 Jan 2021 11:05:31 GMT, Aleksey Shipilev wrote: > What is up with this PR? There are no recorded changes, and tests are failing ;) Weird, I seem to have messed it up. I'll fix it shortly. ------------- PR: https://git.openjdk.java.net/jdk/pull/2202 From rkennke at openjdk.java.net Fri Jan 29 14:45:50 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 29 Jan 2021 14:45:50 GMT Subject: RFR: 8260309: Shenandoah: Clean up ShenandoahBarrierSet [v2] In-Reply-To: <5t_ZDBfj_4BxoJLoWh3R0r6OCh2Q0wc-DNJntvfhW1Q=.925a092e-c1d3-41df-b216-1cbb0b936959@github.com> References: <5t_ZDBfj_4BxoJLoWh3R0r6OCh2Q0wc-DNJntvfhW1Q=.925a092e-c1d3-41df-b216-1cbb0b936959@github.com> Message-ID: > We collected some cruft in ShenandoahBarrierSet. Time to clean it up. > > This fixes/removes a number of includes, fixes some comments and it also removes is_a() and is_aligned() which look like leftovers/requirements from earlier incarnations of the superclass BarrierSet. Using the override keyword would be useful for such situations (btw, are we ok to start using override, nullptr, auto etc in Shenandoah, or do we want to keep it C++ for backporting ease?) > > One thing I was not sure about is the ShenandoahHeap* _heap field. Making it const will likely help the compiler avoid repeated access (e.g. in a number of perf-critical paths like the LRB impl). However, maybe we should get rid of the field altogether and make it explicitely using ShenandoahHeap::heap() and avoid repeated access instead of helping the compiler and hoping for the best? > > Testing: > - [x] hotspot_gc_shenandoah release, fastdebug Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Restore some changes that have been lost during merge - Merge branch 'master' into JDK-8260309 - 8260309: Shenandoah: Clean up ShenandoahBarrierSet ------------- Changes: https://git.openjdk.java.net/jdk/pull/2202/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2202&range=01 Stats: 31 lines in 6 files changed: 4 ins; 19 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/2202.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2202/head:pull/2202 PR: https://git.openjdk.java.net/jdk/pull/2202 From rkennke at openjdk.java.net Fri Jan 29 15:00:41 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 29 Jan 2021 15:00:41 GMT Subject: RFR: 8260309: Shenandoah: Clean up ShenandoahBarrierSet In-Reply-To: References: <5t_ZDBfj_4BxoJLoWh3R0r6OCh2Q0wc-DNJntvfhW1Q=.925a092e-c1d3-41df-b216-1cbb0b936959@github.com> Message-ID: On Fri, 29 Jan 2021 11:16:39 GMT, Roman Kennke wrote: > > What is up with this PR? There are no recorded changes, and tests are failing ;) > > Weird, I seem to have messed it up. I'll fix it shortly. It should be good to review, now. ------------- PR: https://git.openjdk.java.net/jdk/pull/2202 From kvn at openjdk.java.net Fri Jan 29 16:32:43 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 29 Jan 2021 16:32:43 GMT Subject: [jdk16] RFR: 8260632: Build failures after JDK-8253353 In-Reply-To: References: Message-ID: <-2ay1k0rXBxWJKLEAFelmBeTw3xcp-Q3xqb-BFjKeLI=.0d2ec250-d835-4432-8a14-4459edad72ad@github.com> On Fri, 29 Jan 2021 08:20:10 GMT, Aleksey Shipilev wrote: > [JDK-8253353](https://bugs.openjdk.java.net/browse/JDK-8253353) changed the field to `uint16_t`, and now `shenadoahSupport.cpp` code runs into ambiguity choosing between `uint8_t` and `uint16_t` when instantiating `MAX2` macro: > > > max_depth = MAX2(max_depth, lpt->_nest); > ^ > In file included from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/metaprogramming/primitiveConversions.hpp:30:0, > from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/oops/oopHandle.hpp:28, > from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/classfile/systemDictionary.hpp:28, > from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/classfile/javaClasses.hpp:28, > from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp:27: > > Additional testing: > - [x] Linux x86_64 `hotspot_gc_shenandoah` > - [x] Linux x86_64 `tier1` with Shenandoah Good. I approved fix request for JDK 16. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/138 From shade at openjdk.java.net Fri Jan 29 17:50:46 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 29 Jan 2021 17:50:46 GMT Subject: [jdk16] RFR: 8260632: Build failures after JDK-8253353 In-Reply-To: <-2ay1k0rXBxWJKLEAFelmBeTw3xcp-Q3xqb-BFjKeLI=.0d2ec250-d835-4432-8a14-4459edad72ad@github.com> References: <-2ay1k0rXBxWJKLEAFelmBeTw3xcp-Q3xqb-BFjKeLI=.0d2ec250-d835-4432-8a14-4459edad72ad@github.com> Message-ID: On Fri, 29 Jan 2021 16:29:44 GMT, Vladimir Kozlov wrote: >> [JDK-8253353](https://bugs.openjdk.java.net/browse/JDK-8253353) changed the field to `uint16_t`, and now `shenadoahSupport.cpp` code runs into ambiguity choosing between `uint8_t` and `uint16_t` when instantiating `MAX2` macro: >> >> >> max_depth = MAX2(max_depth, lpt->_nest); >> ^ >> In file included from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/metaprogramming/primitiveConversions.hpp:30:0, >> from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/oops/oopHandle.hpp:28, >> from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/classfile/systemDictionary.hpp:28, >> from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/classfile/javaClasses.hpp:28, >> from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp:27: >> >> Additional testing: >> - [x] Linux x86_64 `hotspot_gc_shenandoah` >> - [x] Linux x86_64 `tier1` with Shenandoah > > Good. I approved fix request for JDK 16. Thank you. ------------- PR: https://git.openjdk.java.net/jdk16/pull/138 From shade at openjdk.java.net Fri Jan 29 17:50:47 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 29 Jan 2021 17:50:47 GMT Subject: [jdk16] Integrated: 8260632: Build failures after JDK-8253353 In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 08:20:10 GMT, Aleksey Shipilev wrote: > [JDK-8253353](https://bugs.openjdk.java.net/browse/JDK-8253353) changed the field to `uint16_t`, and now `shenadoahSupport.cpp` code runs into ambiguity choosing between `uint8_t` and `uint16_t` when instantiating `MAX2` macro: > > > max_depth = MAX2(max_depth, lpt->_nest); > ^ > In file included from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/metaprogramming/primitiveConversions.hpp:30:0, > from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/oops/oopHandle.hpp:28, > from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/classfile/systemDictionary.hpp:28, > from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/classfile/javaClasses.hpp:28, > from /home/buildbot/worker/build-jdk16u-linux/build/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp:27: > > Additional testing: > - [x] Linux x86_64 `hotspot_gc_shenandoah` > - [x] Linux x86_64 `tier1` with Shenandoah This pull request has now been integrated. Changeset: bc41bb10 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16/commit/bc41bb10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8260632: Build failures after JDK-8253353 Reviewed-by: stuefe, thartmann, kvn ------------- PR: https://git.openjdk.java.net/jdk16/pull/138 From mvejen at gmail.com Thu Jan 21 10:16:31 2021 From: mvejen at gmail.com (Morten Vejen Nielsen) Date: Thu, 21 Jan 2021 10:16:31 -0000 Subject: Shenandoah SIGSEGV crashes on jdk8 build Message-ID: Hi, I'm not sure if this is the right place to post this, if it isn't I apologize in advance. We are currently using Shenandoah with Cassandra 3.11 for multi-tenant platform. This is run with the jdk-8 version of the redhat jdk that includes Shenandoah. We are fully aware that this in itself is an experimental setup but we found this to be the best solution to mitigate issues with high gc pauses and request timeouts in cassandra. So far we have had really good experience with this, but we have unfortunately seen a few crashes now where the JVM crashes with a SIGSEGV (0xb) during a high pressure situation. I have attached a hs_err_pid file with the detailed error, unfortunately I don't have a core dump at the moment but we are currently trying to reproduce this error consistently to attain this. At the time it crashed (10:30) we noticed high CPU activity on the system and high GC activity (have attached gc log file). I noticed this logging in gc log, which to me seems to indicate that our gc cant keep up with application allocation rate, so we are currently looking at tuning this. 2021-01-20T10:50:28.918+0000: 4063718.351: Total time for which application threads were stopped: 0.0007702 seconds, Stopping threads took: 0.0000455 seconds Trigger: Average GC time (1201.36 ms) is above the time for allocation rate (739 MB/s) to deplete free headroom (874M) But it seems to me that it shouldn't crash with a SIGSEGV because of this. So I wanted to post this message in case to ask if this is a known issue or if this is a bug? We are using this jdk 8 build: build 1.8.0-builds.shipilev.net-openjdk-shenandoah-jdk8-b766-20201130-testing-b00 And otherwise we are running with default gc settings except for having set: -XX:ParallelGCThreads=16 -XX:ConcGCThreads=5 Best regards Morten