<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
Hi Abdulhakim Unlu,<br>
<br>
Your mail got caught in the mailing list filter because the attached
file was too large.<br>
<br>
<div class="moz-cite-prefix">On 2024-12-27 22:02, Abdülhakim Ünlü
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAKnsem5yXOM-nP9eHQgAm-UXQeL892R1-TgA9npBpi9fAEHY8g@mail.gmail.com">
<div dir="ltr">
<div>Hi, <br>
</div>
<div>I am not sure if this is the right place to post this
issue.</div>
</div>
</blockquote>
<br>
It is. Thanks for reporting this!<br>
<br>
<blockquote type="cite" cite="mid:CAKnsem5yXOM-nP9eHQgAm-UXQeL892R1-TgA9npBpi9fAEHY8g@mail.gmail.com">
<div dir="ltr">
<div> We are testing out ZGC in a Xmx975G JVM. It crashed with
the attached hs_err file. <br>
</div>
<div><br>
</div>
<div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">#
Internal Error (<a class="moz-txt-link-freetext" href="zMarkStackAllocator.cpp:81">zMarkStackAllocator.cpp:81</a>), pid=34334,
tid=38183<br>
# fatal error: Mark stack space exhausted. Use
-XX:ZMarkStackSpaceLimit=<size> to increase the
maximum number of bytes allocated for mark stacks. Current
limit is 8192M.</blockquote>
<br>
</div>
<div>How can I find the right size for ZMarkStackSpaceLimit, so
that jvm does not crash?</div>
<div><br>
</div>
<div>Can ZGC handle this case in a more graceful way ? Can ZGC
adjust ZMarkStackSpaceLimit dynamically ? I mean, in a
production environment, we cannot keep crashing JVM until we
find the right ZMarkStackSpaceLimit value. <br>
</div>
</div>
</blockquote>
<br>
I've taken a look at the provided hs_err file. There's a few
interesting things.<br>
<br>
1) As you show, we run out of mark stack space. This is quite
unexpected. We have seen similar issues in degenerate test-cases,
for example, with extremely long doubly linked lists. We have also
seen things like this when we introduced bugs during the development
of the GC.<br>
<br>
We've talked this through in the team and I think we could rewrite
the code to remove the need to set this limit. I've created a RFE
for this:<br>
<a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/JDK-8347335">https://bugs.openjdk.org/browse/JDK-8347335</a><br>
<br>
However, this will not solve the fact that the mark stacks are
extremely large in your use-case. The next point *might* explain the
reason why the mark stacks are filled up.<br>
<br>
2) You are running with String Deduplication turned on. It turns out
that Generational ZGC tries to deduplicate every single String that
the GC finds to be a live in the system, where as the other GCs skip
short-lived strings. This, together with String Deduplications usage
of weak "handles" and the fact that ZGC treats these handles as
strong roots in the young generation cause otherwise short-lived
objects to get promoted to the old generation. This fills up the old
generation, leading to very long old generation collections. I see
in your logs that you had a 10m long major collection before this
failure. Maybe this is related to why the mark stack space is
filling up.<br>
<br>
I've created a bug to fix the String Deduplication issue:<br>
<a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/JDK-8347337">https://bugs.openjdk.org/browse/JDK-8347337</a><br>
<br>
Do you have a great need for the String Deduplication feature?
Otherwise, I would suggest that you turn it off when running with
ZGC.<br>
<br>
Thanks,<br>
StefanK<br>
<br>
<blockquote type="cite" cite="mid:CAKnsem5yXOM-nP9eHQgAm-UXQeL892R1-TgA9npBpi9fAEHY8g@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>thanks,</div>
<div>Abdulhakim Unlu</div>
</div>
</blockquote>
<br>
</body>
</html>