Re： out of address space

[地上的月影]

Hi Erik




Thanks for your answer, after last time report, I have tried add some logs together with the fragment patch https://bugs.openjdk.org/browse/JDK-8276055. maybe because of last time I haven't built the jdk17 right, I can't reproduce the problem until now this time(the apps running about 3 days, maybe not enough time), I will keep observing for a while.




If it happens again, I will add -Xlog:gc+init and -XX:SoftMaxHeapSize to find more information and give the result data for analysis.
However, since the time it takes to reproduce the problem maybe a week or more, I will report the observation in 2 weeks to let you know the result.




Thanks again




Anjian



------------------ 原始邮件 ------------------
发件人:                                                                                                                        "Erik Osterlund"                                                                                    <erik.osterlund at oracle.com>;
发送时间: 2022年9月27日(星期二) 下午4:15
收件人: "地上的月影"<404450559 at qq.com>;
抄送: "zgc-dev"<zgc-dev at openjdk.org>;
主题: Re: out of address space



 Hi Anjian, 
 
 Thank you for reporting this issue. I have filed a bug for investigating this:
 https://bugs.openjdk.org/browse/JDK-8294425
 
 
 Based on the reported symptoms, it smells like the virtual address space
 has gotten fragmented over time, possibly due to large allocations that
 are too large to move around. We do reserve “a bunch” of extra virtual
 address space to deal with that, but perhaps something is flawed in that
 logic, and you have hit some kind of corner case.
 
 
 If you run -Xlog:gc+init, then we can see how much address space was
 reserved by the GC when the JVM started. This information would be
 very useful to further reason about what has happened. So if we could
 get the output of that logging, that would be great.
 
 
 As a workaround for now, if you would like to force ZGC to reserve more
 virtual address space, you can use the following JVM flags:
 
 
 -Xmx50G -XX:SoftMaxHeapSize=50G -Xmx1T
 
 
 Then ZGC is forced to reserve virtual memory as if the heap could grow
 to 1T, while in fact, the SoftMaxHeapSize will limit heap growth past 50G
 unless the GC can’t keep up. This will ensure that the GC has tons of
 virtual address space at its disposal. If you still run out of virtual address
 space, then the issue is probably not due to virtual address space fragmentation.
 
 
 Thanks,
 /Erik
  
  On 21 Sep 2022, at 08:34, 地上的月影 <404450559 at qq.com> wrote:
 
  Hi everyone
     these days when I use zgc with jdk17, after the app run for a few days, I meet a "out of address space" problem, and cpu raise to nearly 100%, looks like there is infinite loop.
 
 
 Out  of address space 
 Force to lower max java heap size from 50G(100%) to 50G(100%) Out of address space  Force to lower max java heap size from 50G(100%) to 50G(100%) Out of address space  Force to lower max java heap size from 50G(100%) to 50G(100%) 
 after I check the source code, it looks like the problem is in the function ZPageAllocator::alloc_page -> retry loop 
 my profile flame graph also shows that the most cpu take func is alloc_page_finalize 
 ZPageAllocator::alloc_page_finalize 91.92%  ZPageAllocator::alloc_page_create 91.92%    ZVirtualMemoryManager::alloc 90.85%       ZMemoryManager::alloc_from_back 89.07% 
 I have tried to add this fragment patch but it seems not useful https://bugs.openjdk.org/browse/JDK-8276055 how can I fix this or debug this? 
 looking forward to your answers. best wishes！
 -Anjian Wen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/zgc-dev/attachments/20220927/7178e159/attachment-0001.htm>