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@oracle.com>; 发送时间: 2022年9月27日(星期二) 下午4:15 收件人: "地上的月影"<404450559@qq.com>; 抄送: "zgc-dev"<zgc-dev@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@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