Re： out of address space
404450559 at qq.com
Tue Sep 27 08:51:57 UTC 2022
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.
------------------ 原始邮件 ------------------
发件人: "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
Thank you for reporting this issue. I have filed a bug for investigating this:
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.
On 21 Sep 2022, at 08:34, 地上的月影 <404450559 at qq.com> wrote:
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！
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zgc-dev