<div dir="ltr">Thanks Stefan. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 28, 2024 at 5:00 PM Stefan Johansson <<a href="mailto:stefan.johansson@oracle.com">stefan.johansson@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Ravi,<br>
<br>
I'm not sure we actually have humongous allocation failures here. In G1, <br>
when doing a humongous allocation, there is a check if we should start a <br>
concurrent marking cycle before doing the humongous allocations. We will <br>
do the "G1 Humongous Allocation" gc if the G1 policy consider the memory <br>
usage to be too high. So when having a lot of humongous allocations is <br>
not uncommon to see these types of collections.<br>
<br>
The G1New JFR events corresponds to the young collection that kicks off <br>
the concurrent marking. The concurrent marking then sends the G1Old <br>
event. The reason they have the same start time is that the concurrent <br>
marking is viewed as being started by the young collections.<br>
<br>
The humongous allocations do happen in the old generation from the point <br>
of view that they aren't included in the normal young collections but in <br>
JDK 8 they are actually never moved by any collection.<br>
<br>
Hope this helps,<br>
StefanJ<br>
<br>
<br>
On 2024-08-28 09:50, Ravi wrote:<br>
> if we look at the timestamps, both of them are happening at the same time.<br>
> <br>
> On Wed, Aug 28, 2024 at 12:27 PM Kim Barrett <<a href="mailto:kim.barrett@oracle.com" target="_blank">kim.barrett@oracle.com</a> <br>
> <mailto:<a href="mailto:kim.barrett@oracle.com" target="_blank">kim.barrett@oracle.com</a>>> wrote:<br>
> <br>
>     __<br>
> <br>
>     On 8/27/24 5:04 AM, Ravi wrote:<br>
> <br>
>>     Dear Experts,<br>
>><br>
>>     We have an application running on jre 1.8u261 with the below jvm<br>
>>     arguments:<br>
>>      -Xms8g -Xmx8g -XX:MetaspaceSize=2g -XX:MaxMetaspaceSize=2g<br>
>>     -XX:+UseG1GC -XX:ParallelGCThreads=2 -XX:ConcGCThreads=1<br>
>>     -XX:+PrintFlagsFinal<br>
>><br>
>>     From the jfrs, we could see Humongous allocation failures are<br>
>>     happening in the G1New and aswell G1Old spaces:<br>
> <br>
>     I think humongous allocation failure will first attempt a young<br>
>     collection.<br>
>     This may free regions, potentially resulting in a sequence of free<br>
>     regions<br>
>     sufficient to satisfy the humongous allocation request. Only if that<br>
>     fails is<br>
>     a full collection performed.  That seems to be what your trace<br>
>     shows, e.g. a<br>
>     fill (G1Old) collection occurring shortly after the young (G1New)<br>
>     collection<br>
>     in each case.<br>
> <br>
> <br>
> _______________________________________________<br>
> hotspot-gc-use mailing list<br>
> <a href="mailto:hotspot-gc-use@openjdk.org" target="_blank">hotspot-gc-use@openjdk.org</a><br>
> <a href="https://mail.openjdk.org/mailman/listinfo/hotspot-gc-use" rel="noreferrer" target="_blank">https://mail.openjdk.org/mailman/listinfo/hotspot-gc-use</a><br>
</blockquote></div>