Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 07:34:44 GMT, Y. Srinivas Ramakrishna wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update copyright notices > > src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2018, 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Should probably be removed. removed. > src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2018, 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Check if this is necessary. ok. i'll remove. > src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactHeuristics.hpp > line 3: > >> 1: /* >> 2: * Copyright (c) 2018, 2019, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Can be removed? removed. > src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.hpp > line 3: > >> 1: /* >> 2: * Copyright (c) 2018, 2019, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Should be removed? removed. > src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticHeuristics.hpp > line 3: > >> 1: /* >> 2: * Copyright (c) 2018, 2019, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Should be removed? removed. > src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2019, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Should be removed? removed. > src/hotspot/share/gc/shenandoah/mode/shenandoahSATBMode.cpp line 3: > >> 1: /* >> 2: * Copyright (c) 2019, 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Can be removed. removed. > src/hotspot/share/gc/shenandoah/shenandoahBarrierSetClone.inline.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2013, 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Unnecessary. Delete. removed. > src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2013, 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Probably unnecessary. removed. - PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221700458 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221704676 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221706236 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221707142 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221709229 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221710192 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221711143 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221712173 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221713033
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 07:52:35 GMT, Y. Srinivas Ramakrishna wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update copyright notices > > src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Unnecessary. Thanks Ramki for sifting through these again. Sorry I missed so many. I'm making your suggested fixes. - PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221612109
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 07:54:17 GMT, Y. Srinivas Ramakrishna wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update copyright notices > > src/hotspot/share/gc/shenandoah/shenandoahFullGC.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2014, 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Unnecessary fixed. > src/hotspot/share/gc/shenandoah/shenandoahGC.cpp line 3: > >> 1: /* >> 2: * Copyright (c) 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Unnecessary fixed. > src/hotspot/share/gc/shenandoah/shenandoahGC.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Unnecessary fixed. > src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp line 3: > >> 1: /* >> 2: * Copyright (c) 2019, 2022, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Unnecessary? fixed. > src/hotspot/share/gc/shenandoah/shenandoahNumberSeq.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2018, 2019, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Unnecessary? fixed. > src/hotspot/share/gc/shenandoah/shenandoahSTWMark.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > unnecessary. fixed. > src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp line 3: > >> 1: /* >> 2: * Copyright (c) 2019, 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Delete fixed. > src/hotspot/share/gc/shenandoah/shenandoahWorkerPolicy.cpp line 3: > >> 1: /* >> 2: * Copyright (c) 2017, 2019, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Unnecessary fixed. > src/hotspot/share/gc/shenandoah/shenandoahWorkerPolicy.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2017, 2022, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Unnecessary fixed. > test/hotspot/gtest/gc/shenandoah/test_shenandoahNumberSeq.cpp line 2: > >> 1: /* >> 2: * Copyright (c) 2022, 2023, Oracle and/or its affiliates. All rights >> reserved. > > This may be deleted as far as I can tell, or we can just leave it in there. will leave as is. > test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithShenandoah.java line 3: > >> 1: /* >> 2: * Copyright (c) 2016, 2020, Oracle and/or its affiliates. All rights >> reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > General comment: Looking at the history, I might have expected RedHat > copyright headers also for many of these tests, but that isn't a change > that's happened with generational shenandoah. So, nothing for us to do in > this PR. ok. will leave as is. - PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221595485 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221596525 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221597200 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221597834 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221598462 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221599944 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221599533 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221600615 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221601596 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221602442 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221604163
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 07:22:13 GMT, Y. Srinivas Ramakrishna wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update copyright notices > > src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp line > 4: > >> 2: * Copyright (c) 2018, 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright (c) 2012, 2022 SAP SE. All rights reserved. >> 4: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > I believe line 4 should deleted; the copyright header change here is > unnecessary. will remove. I noticed that amazon had also contributed to this file, but changes were very minor. - PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221506981
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 00:39:52 GMT, Kelvin Nilsen wrote: >> OpenJDK Colleagues: >> >> Please review this proposed integration of Generational mode for Shenandoah >> GC under https://bugs.openjdk.org/browse/JDK-8307314. >> >> Generational mode of Shenandoah is enabled by adding >> `-XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a >> command line that already specifies ` -XX:+UseShenandoahGC`. The >> implementation automatically adjusts the sizes of old generation and young >> generation to efficiently utilize the entire heap capacity. Generational >> mode of Shenandoah resembles G1 in the following regards: >> >> 1. Old-generation marking runs concurrently during the time that multiple >> young generation collections run to completion. >> 2. After old-generation marking completes, we perform a sequence of mixed >> collections. Each mixed collection combines collection of young generation >> with evacuation of a portion of the old-generation regions identified for >> collection based on old-generation marking information. >> 3. Unlike G1, young-generation collections and evacuations are entirely >> concurrent, as with single-generation Shenandoah. >> 4. As with single-generation Shenandoah, there is no explicit notion of eden >> and survivor space within the young generation. In practice, regions that >> were most recently allocated tend to have large amounts of garbage and these >> regions tend to be collected with very little effort. Young-generation >> objects that survive garbage collection tend to accumulate in regions that >> hold survivor objects. These regions tend to have smaller amounts of >> garbage, and are less likely to be collected. If they survive a sufficient >> number of young-generation collections, the “survivor” regions are promoted >> into the old generation. >> >> We expect to refine heuristics as we gain experience with more production >> workloads. In the future, we plan to remove the “experimental” qualifier >> from generational mode, at which time we expect that generational mode will >> become the default mode for Shenandoah. >> >> **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, >> gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, >> HyperAlloc, and multiple AWS production workload simulators. We test on >> Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and >> Windows x64. > > Kelvin Nilsen has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright notices test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithShenandoah.java line 3: > 1: /* > 2: * Copyright (c) 2016, 2020, Oracle and/or its affiliates. All rights > reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. General comment: Looking at the history, I might have expected RedHat copyright headers also for many of these tests, but that isn't a change that's happened with generational shenandoah. So, nothing for us to do in this PR. - PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221136441
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 00:39:52 GMT, Kelvin Nilsen wrote: >> OpenJDK Colleagues: >> >> Please review this proposed integration of Generational mode for Shenandoah >> GC under https://bugs.openjdk.org/browse/JDK-8307314. >> >> Generational mode of Shenandoah is enabled by adding >> `-XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a >> command line that already specifies ` -XX:+UseShenandoahGC`. The >> implementation automatically adjusts the sizes of old generation and young >> generation to efficiently utilize the entire heap capacity. Generational >> mode of Shenandoah resembles G1 in the following regards: >> >> 1. Old-generation marking runs concurrently during the time that multiple >> young generation collections run to completion. >> 2. After old-generation marking completes, we perform a sequence of mixed >> collections. Each mixed collection combines collection of young generation >> with evacuation of a portion of the old-generation regions identified for >> collection based on old-generation marking information. >> 3. Unlike G1, young-generation collections and evacuations are entirely >> concurrent, as with single-generation Shenandoah. >> 4. As with single-generation Shenandoah, there is no explicit notion of eden >> and survivor space within the young generation. In practice, regions that >> were most recently allocated tend to have large amounts of garbage and these >> regions tend to be collected with very little effort. Young-generation >> objects that survive garbage collection tend to accumulate in regions that >> hold survivor objects. These regions tend to have smaller amounts of >> garbage, and are less likely to be collected. If they survive a sufficient >> number of young-generation collections, the “survivor” regions are promoted >> into the old generation. >> >> We expect to refine heuristics as we gain experience with more production >> workloads. In the future, we plan to remove the “experimental” qualifier >> from generational mode, at which time we expect that generational mode will >> become the default mode for Shenandoah. >> >> **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, >> gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, >> HyperAlloc, and multiple AWS production workload simulators. We test on >> Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and >> Windows x64. > > Kelvin Nilsen has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright notices test/hotspot/gtest/gc/shenandoah/test_shenandoahNumberSeq.cpp line 2: > 1: /* > 2: * Copyright (c) 2022, 2023, Oracle and/or its affiliates. All rights > reserved. This may be deleted as far as I can tell, or we can just leave it in there. - PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221124209
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 00:39:52 GMT, Kelvin Nilsen wrote: >> OpenJDK Colleagues: >> >> Please review this proposed integration of Generational mode for Shenandoah >> GC under https://bugs.openjdk.org/browse/JDK-8307314. >> >> Generational mode of Shenandoah is enabled by adding >> `-XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a >> command line that already specifies ` -XX:+UseShenandoahGC`. The >> implementation automatically adjusts the sizes of old generation and young >> generation to efficiently utilize the entire heap capacity. Generational >> mode of Shenandoah resembles G1 in the following regards: >> >> 1. Old-generation marking runs concurrently during the time that multiple >> young generation collections run to completion. >> 2. After old-generation marking completes, we perform a sequence of mixed >> collections. Each mixed collection combines collection of young generation >> with evacuation of a portion of the old-generation regions identified for >> collection based on old-generation marking information. >> 3. Unlike G1, young-generation collections and evacuations are entirely >> concurrent, as with single-generation Shenandoah. >> 4. As with single-generation Shenandoah, there is no explicit notion of eden >> and survivor space within the young generation. In practice, regions that >> were most recently allocated tend to have large amounts of garbage and these >> regions tend to be collected with very little effort. Young-generation >> objects that survive garbage collection tend to accumulate in regions that >> hold survivor objects. These regions tend to have smaller amounts of >> garbage, and are less likely to be collected. If they survive a sufficient >> number of young-generation collections, the “survivor” regions are promoted >> into the old generation. >> >> We expect to refine heuristics as we gain experience with more production >> workloads. In the future, we plan to remove the “experimental” qualifier >> from generational mode, at which time we expect that generational mode will >> become the default mode for Shenandoah. >> >> **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, >> gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, >> HyperAlloc, and multiple AWS production workload simulators. We test on >> Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and >> Windows x64. > > Kelvin Nilsen has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright notices src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp line 3: > 1: /* > 2: * Copyright (c) 2019, 2022, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Unnecessary? src/hotspot/share/gc/shenandoah/shenandoahNumberSeq.hpp line 3: > 1: /* > 2: * Copyright (c) 2018, 2019, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Unnecessary? src/hotspot/share/gc/shenandoah/shenandoahSTWMark.hpp line 3: > 1: /* > 2: * Copyright (c) 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. unnecessary. src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp line 3: > 1: /* > 2: * Copyright (c) 2019, 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Delete src/hotspot/share/gc/shenandoah/shenandoahWorkerPolicy.cpp line 3: > 1: /* > 2: * Copyright (c) 2017, 2019, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Unnecessary src/hotspot/share/gc/shenandoah/shenandoahWorkerPolicy.hpp line 3: > 1: /* > 2: * Copyright (c) 2017, 2022, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Unnecessary - PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221104857 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221106767 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221110530 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221113191 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221115925 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221116941
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 00:39:52 GMT, Kelvin Nilsen wrote: >> OpenJDK Colleagues: >> >> Please review this proposed integration of Generational mode for Shenandoah >> GC under https://bugs.openjdk.org/browse/JDK-8307314. >> >> Generational mode of Shenandoah is enabled by adding >> `-XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a >> command line that already specifies ` -XX:+UseShenandoahGC`. The >> implementation automatically adjusts the sizes of old generation and young >> generation to efficiently utilize the entire heap capacity. Generational >> mode of Shenandoah resembles G1 in the following regards: >> >> 1. Old-generation marking runs concurrently during the time that multiple >> young generation collections run to completion. >> 2. After old-generation marking completes, we perform a sequence of mixed >> collections. Each mixed collection combines collection of young generation >> with evacuation of a portion of the old-generation regions identified for >> collection based on old-generation marking information. >> 3. Unlike G1, young-generation collections and evacuations are entirely >> concurrent, as with single-generation Shenandoah. >> 4. As with single-generation Shenandoah, there is no explicit notion of eden >> and survivor space within the young generation. In practice, regions that >> were most recently allocated tend to have large amounts of garbage and these >> regions tend to be collected with very little effort. Young-generation >> objects that survive garbage collection tend to accumulate in regions that >> hold survivor objects. These regions tend to have smaller amounts of >> garbage, and are less likely to be collected. If they survive a sufficient >> number of young-generation collections, the “survivor” regions are promoted >> into the old generation. >> >> We expect to refine heuristics as we gain experience with more production >> workloads. In the future, we plan to remove the “experimental” qualifier >> from generational mode, at which time we expect that generational mode will >> become the default mode for Shenandoah. >> >> **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, >> gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, >> HyperAlloc, and multiple AWS production workload simulators. We test on >> Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and >> Windows x64. > > Kelvin Nilsen has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright notices src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.hpp line 3: > 1: /* > 2: * Copyright (c) 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Unnecessary. src/hotspot/share/gc/shenandoah/shenandoahFullGC.hpp line 3: > 1: /* > 2: * Copyright (c) 2014, 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Unnecessary src/hotspot/share/gc/shenandoah/shenandoahGC.cpp line 3: > 1: /* > 2: * Copyright (c) 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Unnecessary src/hotspot/share/gc/shenandoah/shenandoahGC.hpp line 3: > 1: /* > 2: * Copyright (c) 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Unnecessary - PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221087455 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221091340 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221092320 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221093246
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 00:39:52 GMT, Kelvin Nilsen wrote: >> OpenJDK Colleagues: >> >> Please review this proposed integration of Generational mode for Shenandoah >> GC under https://bugs.openjdk.org/browse/JDK-8307314. >> >> Generational mode of Shenandoah is enabled by adding >> `-XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a >> command line that already specifies ` -XX:+UseShenandoahGC`. The >> implementation automatically adjusts the sizes of old generation and young >> generation to efficiently utilize the entire heap capacity. Generational >> mode of Shenandoah resembles G1 in the following regards: >> >> 1. Old-generation marking runs concurrently during the time that multiple >> young generation collections run to completion. >> 2. After old-generation marking completes, we perform a sequence of mixed >> collections. Each mixed collection combines collection of young generation >> with evacuation of a portion of the old-generation regions identified for >> collection based on old-generation marking information. >> 3. Unlike G1, young-generation collections and evacuations are entirely >> concurrent, as with single-generation Shenandoah. >> 4. As with single-generation Shenandoah, there is no explicit notion of eden >> and survivor space within the young generation. In practice, regions that >> were most recently allocated tend to have large amounts of garbage and these >> regions tend to be collected with very little effort. Young-generation >> objects that survive garbage collection tend to accumulate in regions that >> hold survivor objects. These regions tend to have smaller amounts of >> garbage, and are less likely to be collected. If they survive a sufficient >> number of young-generation collections, the “survivor” regions are promoted >> into the old generation. >> >> We expect to refine heuristics as we gain experience with more production >> workloads. In the future, we plan to remove the “experimental” qualifier >> from generational mode, at which time we expect that generational mode will >> become the default mode for Shenandoah. >> >> **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, >> gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, >> HyperAlloc, and multiple AWS production workload simulators. We test on >> Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and >> Windows x64. > > Kelvin Nilsen has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright notices src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp line 3: > 1: /* > 2: * Copyright (c) 2013, 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Probably unnecessary. - PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221076190
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 00:39:52 GMT, Kelvin Nilsen wrote: >> OpenJDK Colleagues: >> >> Please review this proposed integration of Generational mode for Shenandoah >> GC under https://bugs.openjdk.org/browse/JDK-8307314. >> >> Generational mode of Shenandoah is enabled by adding >> `-XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a >> command line that already specifies ` -XX:+UseShenandoahGC`. The >> implementation automatically adjusts the sizes of old generation and young >> generation to efficiently utilize the entire heap capacity. Generational >> mode of Shenandoah resembles G1 in the following regards: >> >> 1. Old-generation marking runs concurrently during the time that multiple >> young generation collections run to completion. >> 2. After old-generation marking completes, we perform a sequence of mixed >> collections. Each mixed collection combines collection of young generation >> with evacuation of a portion of the old-generation regions identified for >> collection based on old-generation marking information. >> 3. Unlike G1, young-generation collections and evacuations are entirely >> concurrent, as with single-generation Shenandoah. >> 4. As with single-generation Shenandoah, there is no explicit notion of eden >> and survivor space within the young generation. In practice, regions that >> were most recently allocated tend to have large amounts of garbage and these >> regions tend to be collected with very little effort. Young-generation >> objects that survive garbage collection tend to accumulate in regions that >> hold survivor objects. These regions tend to have smaller amounts of >> garbage, and are less likely to be collected. If they survive a sufficient >> number of young-generation collections, the “survivor” regions are promoted >> into the old generation. >> >> We expect to refine heuristics as we gain experience with more production >> workloads. In the future, we plan to remove the “experimental” qualifier >> from generational mode, at which time we expect that generational mode will >> become the default mode for Shenandoah. >> >> **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, >> gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, >> HyperAlloc, and multiple AWS production workload simulators. We test on >> Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and >> Windows x64. > > Kelvin Nilsen has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright notices > Thanks Thomas for the feedback: > > These proposed changes represent improvements to both Generational and > Non-generational modes of operation. We can revert if that is desired, or we > can specialize Generational versions of these parameters so that they can > have different values in different modes, but here is a bit of background. > We've done considerable testing on a variety of synthetic workloads and some > limited testing on production workloads. As we move towards upstream > integration, we expect this will help us gain exposure to more production > workloads. The following changes were based on results of this testing: > Hi Kelvin, thanks for the thorough explanations! It is a pity that these valuable insights are buried in a GH discussion and these changes inside such a large patch. I also looked at the originating patch in openjdk/shenandoah, which I assume is your development repo for Shenandoah (?). Could I convince you to adapt the JBS issue process in the shenandoah repo (so, opening an issue on JBS, with some clear explanation, then fixing the bug)? Roman convinced me of this for the Lilliput repository, and now I think the added work is well worth it. JBS is a treasure trove of insights, if filled with care, and can help us for many years. Some more questions about `ShenandoahFullGCThreshold`: I am looking at the nice ASCII art in `ShenandoahControlThread::service_concurrent_normal_cycle`. IIUC, the cycle goes: Concurrent GC -> Alloc failure -> n x Degenerated GC -> Alloc Failure -> Full GC right? So the change is now in how often we try a degenerated GC before falling back to a full GC? With GenShen, does a degenerated GC still collect only the young regions? And only FullGC does collect all regions? Are comment and ASCII-art still correct for GenShen? E.g. the comment says: // If second allocation failure happens during Degenerated GC cycle (for example, when GC // tries to evac something and no memory is available), cycle degrades to Full GC. Is "second allocation failure" correct? Since even before this patch, we tried three times before falling back to a Full GC. Thank you, Thomas - PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1580127311
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 00:39:52 GMT, Kelvin Nilsen wrote: >> OpenJDK Colleagues: >> >> Please review this proposed integration of Generational mode for Shenandoah >> GC under https://bugs.openjdk.org/browse/JDK-8307314. >> >> Generational mode of Shenandoah is enabled by adding >> `-XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a >> command line that already specifies ` -XX:+UseShenandoahGC`. The >> implementation automatically adjusts the sizes of old generation and young >> generation to efficiently utilize the entire heap capacity. Generational >> mode of Shenandoah resembles G1 in the following regards: >> >> 1. Old-generation marking runs concurrently during the time that multiple >> young generation collections run to completion. >> 2. After old-generation marking completes, we perform a sequence of mixed >> collections. Each mixed collection combines collection of young generation >> with evacuation of a portion of the old-generation regions identified for >> collection based on old-generation marking information. >> 3. Unlike G1, young-generation collections and evacuations are entirely >> concurrent, as with single-generation Shenandoah. >> 4. As with single-generation Shenandoah, there is no explicit notion of eden >> and survivor space within the young generation. In practice, regions that >> were most recently allocated tend to have large amounts of garbage and these >> regions tend to be collected with very little effort. Young-generation >> objects that survive garbage collection tend to accumulate in regions that >> hold survivor objects. These regions tend to have smaller amounts of >> garbage, and are less likely to be collected. If they survive a sufficient >> number of young-generation collections, the “survivor” regions are promoted >> into the old generation. >> >> We expect to refine heuristics as we gain experience with more production >> workloads. In the future, we plan to remove the “experimental” qualifier >> from generational mode, at which time we expect that generational mode will >> become the default mode for Shenandoah. >> >> **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, >> gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, >> HyperAlloc, and multiple AWS production workload simulators. We test on >> Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and >> Windows x64. > > Kelvin Nilsen has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright notices src/hotspot/share/gc/shenandoah/shenandoahBarrierSetClone.inline.hpp line 3: > 1: /* > 2: * Copyright (c) 2013, 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Unnecessary. Delete. - PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221070505
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 00:39:52 GMT, Kelvin Nilsen wrote: >> OpenJDK Colleagues: >> >> Please review this proposed integration of Generational mode for Shenandoah >> GC under https://bugs.openjdk.org/browse/JDK-8307314. >> >> Generational mode of Shenandoah is enabled by adding >> `-XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a >> command line that already specifies ` -XX:+UseShenandoahGC`. The >> implementation automatically adjusts the sizes of old generation and young >> generation to efficiently utilize the entire heap capacity. Generational >> mode of Shenandoah resembles G1 in the following regards: >> >> 1. Old-generation marking runs concurrently during the time that multiple >> young generation collections run to completion. >> 2. After old-generation marking completes, we perform a sequence of mixed >> collections. Each mixed collection combines collection of young generation >> with evacuation of a portion of the old-generation regions identified for >> collection based on old-generation marking information. >> 3. Unlike G1, young-generation collections and evacuations are entirely >> concurrent, as with single-generation Shenandoah. >> 4. As with single-generation Shenandoah, there is no explicit notion of eden >> and survivor space within the young generation. In practice, regions that >> were most recently allocated tend to have large amounts of garbage and these >> regions tend to be collected with very little effort. Young-generation >> objects that survive garbage collection tend to accumulate in regions that >> hold survivor objects. These regions tend to have smaller amounts of >> garbage, and are less likely to be collected. If they survive a sufficient >> number of young-generation collections, the “survivor” regions are promoted >> into the old generation. >> >> We expect to refine heuristics as we gain experience with more production >> workloads. In the future, we plan to remove the “experimental” qualifier >> from generational mode, at which time we expect that generational mode will >> become the default mode for Shenandoah. >> >> **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, >> gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, >> HyperAlloc, and multiple AWS production workload simulators. We test on >> Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and >> Windows x64. > > Kelvin Nilsen has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright notices src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.cpp line 4: > 2: * Copyright (c) 2018, 2020, Red Hat, Inc. All rights reserved. > 3: * Copyright (c) 2020, 2021, Huawei Technologies Co., Ltd. All rights > reserved. > 4: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Remove this line; extent of changes doesn't warrant copyright header change. src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.hpp line 3: > 1: /* > 2: * Copyright (c) 2018, 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Should probably be removed. src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.hpp line 3: > 1: /* > 2: * Copyright (c) 2018, 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Check if this is necessary. src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp line 4: > 2: * Copyright (c) 2015, 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright (C) 2022 THL A29 Limited, a Tencent company. All rights > reserved. > 4: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Should be removed. src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactHeuristics.hpp line 3: > 1: /* > 2: * Copyright (c) 2018, 2019, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Can be removed? src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.hpp line 3: > 1: /* > 2: * Copyright (c) 2018, 2019, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Should be removed? src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticHeuristics.hpp line 3: > 1: /* > 2: * Copyright (c) 2018, 2019, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Should be removed? src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.hpp line 3: > 1: /* > 2: * Copyright (c) 2019, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Should be removed? src/hotspot/share/gc/shenandoah/mode/shenandoahSATBMode.cpp line 3: > 1: /* > 2: * Copyright (c) 2019, 2021, Red Hat, Inc. All rights reserved. > 3: * C
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 00:39:52 GMT, Kelvin Nilsen wrote: >> OpenJDK Colleagues: >> >> Please review this proposed integration of Generational mode for Shenandoah >> GC under https://bugs.openjdk.org/browse/JDK-8307314. >> >> Generational mode of Shenandoah is enabled by adding >> `-XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a >> command line that already specifies ` -XX:+UseShenandoahGC`. The >> implementation automatically adjusts the sizes of old generation and young >> generation to efficiently utilize the entire heap capacity. Generational >> mode of Shenandoah resembles G1 in the following regards: >> >> 1. Old-generation marking runs concurrently during the time that multiple >> young generation collections run to completion. >> 2. After old-generation marking completes, we perform a sequence of mixed >> collections. Each mixed collection combines collection of young generation >> with evacuation of a portion of the old-generation regions identified for >> collection based on old-generation marking information. >> 3. Unlike G1, young-generation collections and evacuations are entirely >> concurrent, as with single-generation Shenandoah. >> 4. As with single-generation Shenandoah, there is no explicit notion of eden >> and survivor space within the young generation. In practice, regions that >> were most recently allocated tend to have large amounts of garbage and these >> regions tend to be collected with very little effort. Young-generation >> objects that survive garbage collection tend to accumulate in regions that >> hold survivor objects. These regions tend to have smaller amounts of >> garbage, and are less likely to be collected. If they survive a sufficient >> number of young-generation collections, the “survivor” regions are promoted >> into the old generation. >> >> We expect to refine heuristics as we gain experience with more production >> workloads. In the future, we plan to remove the “experimental” qualifier >> from generational mode, at which time we expect that generational mode will >> become the default mode for Shenandoah. >> >> **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, >> gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, >> HyperAlloc, and multiple AWS production workload simulators. We test on >> Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and >> Windows x64. > > Kelvin Nilsen has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright notices src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp line 4: > 2: * Copyright (c) 2018, 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright (c) 2012, 2022 SAP SE. All rights reserved. > 4: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. I believe line 4 should deleted; the copyright header change here is unnecessary. - PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221032491
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 00:39:52 GMT, Kelvin Nilsen wrote: >> OpenJDK Colleagues: >> >> Please review this proposed integration of Generational mode for Shenandoah >> GC under https://bugs.openjdk.org/browse/JDK-8307314. >> >> Generational mode of Shenandoah is enabled by adding >> `-XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a >> command line that already specifies ` -XX:+UseShenandoahGC`. The >> implementation automatically adjusts the sizes of old generation and young >> generation to efficiently utilize the entire heap capacity. Generational >> mode of Shenandoah resembles G1 in the following regards: >> >> 1. Old-generation marking runs concurrently during the time that multiple >> young generation collections run to completion. >> 2. After old-generation marking completes, we perform a sequence of mixed >> collections. Each mixed collection combines collection of young generation >> with evacuation of a portion of the old-generation regions identified for >> collection based on old-generation marking information. >> 3. Unlike G1, young-generation collections and evacuations are entirely >> concurrent, as with single-generation Shenandoah. >> 4. As with single-generation Shenandoah, there is no explicit notion of eden >> and survivor space within the young generation. In practice, regions that >> were most recently allocated tend to have large amounts of garbage and these >> regions tend to be collected with very little effort. Young-generation >> objects that survive garbage collection tend to accumulate in regions that >> hold survivor objects. These regions tend to have smaller amounts of >> garbage, and are less likely to be collected. If they survive a sufficient >> number of young-generation collections, the “survivor” regions are promoted >> into the old generation. >> >> We expect to refine heuristics as we gain experience with more production >> workloads. In the future, we plan to remove the “experimental” qualifier >> from generational mode, at which time we expect that generational mode will >> become the default mode for Shenandoah. >> >> **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, >> gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, >> HyperAlloc, and multiple AWS production workload simulators. We test on >> Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and >> Windows x64. > > Kelvin Nilsen has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright notices > Hi, I have built this pr based on > [aa85a90](https://github.com/openjdk/jdk/commit/aa85a9073e2a71d6bf920409e739d555f9dcf302), > Tier1 tests failed on `gc/TestAllocHumongousFragment.java#generational` on > Linux/RISC-V with the following output: > > ``` > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (shenandoahVerifier.cpp:1244), pid=2951116, tid=2951124 > # Error: Verify init-mark remembered set violation; clean card should be > dirty > # > # JRE version: OpenJDK Runtime Environment (21.0) (build > 21-internal-adhoc.ubuntu.jdk) > # Java VM: OpenJDK 64-Bit Server VM (21-internal-adhoc.ubuntu.jdk, mixed > mode, sharing, tiered, compressed oops, compressed class ptrs, shenandoah gc, > linux-riscv64) > ``` > > Looks like Generational Shenandoah does not fully support RISC-V port, should > we disable this test on RISC-V port for now? Fixed (platform disabled) by @kdnilsen in https://github.com/openjdk/jdk/pull/14185/commits/cc149904d76c78355fc994da171f0f21411e903f - PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1579829038
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
> OpenJDK Colleagues: > > Please review this proposed integration of Generational mode for Shenandoah > GC under https://bugs.openjdk.org/browse/JDK-8307314. > > Generational mode of Shenandoah is enabled by adding > `-XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a > command line that already specifies ` -XX:+UseShenandoahGC`. The > implementation automatically adjusts the sizes of old generation and young > generation to efficiently utilize the entire heap capacity. Generational > mode of Shenandoah resembles G1 in the following regards: > > 1. Old-generation marking runs concurrently during the time that multiple > young generation collections run to completion. > 2. After old-generation marking completes, we perform a sequence of mixed > collections. Each mixed collection combines collection of young generation > with evacuation of a portion of the old-generation regions identified for > collection based on old-generation marking information. > 3. Unlike G1, young-generation collections and evacuations are entirely > concurrent, as with single-generation Shenandoah. > 4. As with single-generation Shenandoah, there is no explicit notion of eden > and survivor space within the young generation. In practice, regions that > were most recently allocated tend to have large amounts of garbage and these > regions tend to be collected with very little effort. Young-generation > objects that survive garbage collection tend to accumulate in regions that > hold survivor objects. These regions tend to have smaller amounts of > garbage, and are less likely to be collected. If they survive a sufficient > number of young-generation collections, the “survivor” regions are promoted > into the old generation. > > We expect to refine heuristics as we gain experience with more production > workloads. In the future, we plan to remove the “experimental” qualifier > from generational mode, at which time we expect that generational mode will > become the default mode for Shenandoah. > > **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, > gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, > HyperAlloc, and multiple AWS production workload simulators. We test on Linux > x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and Windows > x64. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Update copyright notices - Changes: - all: https://git.openjdk.org/jdk/pull/14185/files - new: https://git.openjdk.org/jdk/pull/14185/files/8f9e2a84..f6c073a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=07-08 Stats: 7 lines in 6 files changed: 0 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14185.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14185/head:pull/14185 PR: https://git.openjdk.org/jdk/pull/14185
