From mailravi at gmail.com Tue Aug 27 09:04:22 2024 From: mailravi at gmail.com (Ravi) Date: Tue, 27 Aug 2024 14:34:22 +0530 Subject: Regarding Humongous Allocation - G1GC Message-ID: Dear Experts, We have an application running on jre 1.8u261 with the below jvm arguments: -Xms8g -Xmx8g -XX:MetaspaceSize=2g -XX:MaxMetaspaceSize=2g -XX:+UseG1GC -XX:ParallelGCThreads=2 -XX:ConcGCThreads=1 -XX:+PrintFlagsFinal >From the jfrs, we could see Humongous allocation failures are happening in the G1New and aswell G1Old spaces: GC ID Cause Collector Name Longest Pause Sum of Pauses Final References Weak References Soft References Phantom References Duration Start Time End Time Used Heap Before GC Used Heap After GC Used Heap Delta Duration in seconds 7,156 G1 Humongous Allocation G1New 164.046 ms 164.046 ms 128 3 0 0 164.046 ms 7/22/24, 3:53:52.858 AM 7/22/24, 3:53:53.022 AM 3.73 GiB 3.33 GiB -407 MiB 0.164046 7,157 G1 Humongous Allocation G1Old 182.956 ms 197.682 ms 3 72,074 3,638 24 2.831 s 7/22/24, 3:53:52.858 AM 7/22/24, 3:53:55.689 AM 3.73 GiB 2.58 GiB -1.14 GiB 2.831 7,178 G1 Humongous Allocation G1New 88.197 ms 88.197 ms 4 4 0 0 88.197 ms 7/22/24, 3:54:05.838 AM 7/22/24, 3:54:05.926 AM 3.74 GiB 3.49 GiB -258 MiB 0.088197 7,179 G1 Humongous Allocation G1Old 183.655 ms 197.983 ms 1 71,947 3,640 24 2.558 s 7/22/24, 3:54:05.838 AM 7/22/24, 3:54:08.396 AM 3.74 GiB 2.66 GiB -1.08 GiB 2.558 But the java tuning document mentions that humongous allocation happens in the old generation. How do we interpret this above data? Under which circumstances do we see this kind of behaviour (humongous allocation failure in g1new space), ref: https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc_tuning.html Could you please throw some light. Thanks in advance Ravi -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Wed Aug 28 06:57:33 2024 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 28 Aug 2024 02:57:33 -0400 Subject: Regarding Humongous Allocation - G1GC In-Reply-To: References: Message-ID: On 8/27/24 5:04 AM, Ravi wrote: > Dear Experts, > > We have an application running on jre 1.8u261 with the below jvm > arguments: > ?-Xms8g -Xmx8g -XX:MetaspaceSize=2g -XX:MaxMetaspaceSize=2g > -XX:+UseG1GC -XX:ParallelGCThreads=2 -XX:ConcGCThreads=1 > -XX:+PrintFlagsFinal > > From the jfrs, we could see Humongous allocation failures are > happening in the G1New and aswell?G1Old spaces: I think humongous allocation failure will first attempt a young collection. This may free regions, potentially resulting in a sequence of free regions sufficient to satisfy the humongous allocation request. Only if that fails is a full collection performed.? That seems to be what your trace shows, e.g. a fill (G1Old) collection occurring shortly after the young (G1New) collection in each case. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailravi at gmail.com Wed Aug 28 07:50:57 2024 From: mailravi at gmail.com (Ravi) Date: Wed, 28 Aug 2024 13:20:57 +0530 Subject: Regarding Humongous Allocation - G1GC In-Reply-To: References: Message-ID: if we look at the timestamps, both of them are happening at the same time. On Wed, Aug 28, 2024 at 12:27?PM Kim Barrett wrote: > On 8/27/24 5:04 AM, Ravi wrote: > > Dear Experts, > > We have an application running on jre 1.8u261 with the below jvm > arguments: > -Xms8g -Xmx8g -XX:MetaspaceSize=2g -XX:MaxMetaspaceSize=2g -XX:+UseG1GC > -XX:ParallelGCThreads=2 -XX:ConcGCThreads=1 -XX:+PrintFlagsFinal > > From the jfrs, we could see Humongous allocation failures are happening in > the G1New and aswell G1Old spaces: > > I think humongous allocation failure will first attempt a young collection. > This may free regions, potentially resulting in a sequence of free regions > sufficient to satisfy the humongous allocation request. Only if that fails > is > a full collection performed. That seems to be what your trace shows, e.g. > a > fill (G1Old) collection occurring shortly after the young (G1New) > collection > in each case. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.johansson at oracle.com Wed Aug 28 11:30:13 2024 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 28 Aug 2024 13:30:13 +0200 Subject: Regarding Humongous Allocation - G1GC In-Reply-To: References: Message-ID: Hi Ravi, I'm not sure we actually have humongous allocation failures here. In G1, when doing a humongous allocation, there is a check if we should start a concurrent marking cycle before doing the humongous allocations. We will do the "G1 Humongous Allocation" gc if the G1 policy consider the memory usage to be too high. So when having a lot of humongous allocations is not uncommon to see these types of collections. The G1New JFR events corresponds to the young collection that kicks off the concurrent marking. The concurrent marking then sends the G1Old event. The reason they have the same start time is that the concurrent marking is viewed as being started by the young collections. The humongous allocations do happen in the old generation from the point of view that they aren't included in the normal young collections but in JDK 8 they are actually never moved by any collection. Hope this helps, StefanJ On 2024-08-28 09:50, Ravi wrote: > if we look at the timestamps, both of them are happening at the same time. > > On Wed, Aug 28, 2024 at 12:27?PM Kim Barrett > wrote: > > __ > > On 8/27/24 5:04 AM, Ravi wrote: > >> Dear Experts, >> >> We have an application running on jre 1.8u261 with the below jvm >> arguments: >> ?-Xms8g -Xmx8g -XX:MetaspaceSize=2g -XX:MaxMetaspaceSize=2g >> -XX:+UseG1GC -XX:ParallelGCThreads=2 -XX:ConcGCThreads=1 >> -XX:+PrintFlagsFinal >> >> From the jfrs, we could see Humongous allocation failures are >> happening in the G1New and aswell?G1Old spaces: > > I think humongous allocation failure will first attempt a young > collection. > This may free regions, potentially resulting in a sequence of free > regions > sufficient to satisfy the humongous allocation request. Only if that > fails is > a full collection performed.? That seems to be what your trace > shows, e.g. a > fill (G1Old) collection occurring shortly after the young (G1New) > collection > in each case. > > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.org > https://mail.openjdk.org/mailman/listinfo/hotspot-gc-use From mailravi at gmail.com Wed Aug 28 14:57:25 2024 From: mailravi at gmail.com (Ravi) Date: Wed, 28 Aug 2024 20:27:25 +0530 Subject: Regarding Humongous Allocation - G1GC In-Reply-To: References: Message-ID: Thanks Stefan. On Wed, Aug 28, 2024 at 5:00?PM Stefan Johansson < stefan.johansson at oracle.com> wrote: > Hi Ravi, > > I'm not sure we actually have humongous allocation failures here. In G1, > when doing a humongous allocation, there is a check if we should start a > concurrent marking cycle before doing the humongous allocations. We will > do the "G1 Humongous Allocation" gc if the G1 policy consider the memory > usage to be too high. So when having a lot of humongous allocations is > not uncommon to see these types of collections. > > The G1New JFR events corresponds to the young collection that kicks off > the concurrent marking. The concurrent marking then sends the G1Old > event. The reason they have the same start time is that the concurrent > marking is viewed as being started by the young collections. > > The humongous allocations do happen in the old generation from the point > of view that they aren't included in the normal young collections but in > JDK 8 they are actually never moved by any collection. > > Hope this helps, > StefanJ > > > On 2024-08-28 09:50, Ravi wrote: > > if we look at the timestamps, both of them are happening at the same > time. > > > > On Wed, Aug 28, 2024 at 12:27?PM Kim Barrett > > wrote: > > > > __ > > > > On 8/27/24 5:04 AM, Ravi wrote: > > > >> Dear Experts, > >> > >> We have an application running on jre 1.8u261 with the below jvm > >> arguments: > >> -Xms8g -Xmx8g -XX:MetaspaceSize=2g -XX:MaxMetaspaceSize=2g > >> -XX:+UseG1GC -XX:ParallelGCThreads=2 -XX:ConcGCThreads=1 > >> -XX:+PrintFlagsFinal > >> > >> From the jfrs, we could see Humongous allocation failures are > >> happening in the G1New and aswell G1Old spaces: > > > > I think humongous allocation failure will first attempt a young > > collection. > > This may free regions, potentially resulting in a sequence of free > > regions > > sufficient to satisfy the humongous allocation request. Only if that > > fails is > > a full collection performed. That seems to be what your trace > > shows, e.g. a > > fill (G1Old) collection occurring shortly after the young (G1New) > > collection > > in each case. > > > > > > _______________________________________________ > > hotspot-gc-use mailing list > > hotspot-gc-use at openjdk.org > > https://mail.openjdk.org/mailman/listinfo/hotspot-gc-use > -------------- next part -------------- An HTML attachment was scrubbed... URL: