out of address space
Erik Osterlund
erik.osterlund at oracle.com
Tue Sep 27 08:15:15 UTC 2022
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<mailto: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/54ea6a5e/attachment-0001.htm>
More information about the zgc-dev
mailing list