<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I don't have any objection to this. I only mentioned BufferPoolMXBean to<br>show that memory for direct and mapped buffers is already exposed for<br>monitoring purposes. Also direct buffers are a clear case where the<br>memory is kept alive by live objects and at the same time have a runtime<br>imposed limit. With the foreign memory API (Project Panama) it means<br>there will also be memory segments that are part of lifecycles managed<br>by memory sessions - in time, these will also be resources that may need<br>to be monitored and maybe trigger heap dumps / OOME actions too.</blockquote><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><br></div><div>Great! Thanks for the feedback. I'll proceed with the RFR.</div><div><br></div>+1 for the foreign memory API's case as well. In JDK-8294052's comment, I too mentioned OOME from jdk/internal/foreign/ArenaAllocator.java could benefit from supporting these flags.</div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><br></div><div dir="ltr">-Man</div></div></div><br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 25, 2022 at 1:10 AM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 23/09/2022 23:24, Man Cao wrote:<br>
> :<br>
><br>
> Yes. I completely agree that the OOMEs should be analyzed case by case.<br>
> Also completely agree that the OOMEs for large array allocations do <br>
> not need to handle these JVM flags.<br>
<br>
I think OOME has been over used and if we could go back in time then <br>
maybe things would be different and OOME would not be thrown for some of <br>
these cases.<br>
<br>
<br>
> :<br>
><br>
> It sounds like I could proceed sending the RFR to support these JVM <br>
> flags for direct memory OOME?<br>
> In our case, the application sets -XX:MaxDirectMemorySize and it ran <br>
> out of this limit.<br>
> While bumping up MaxDirectMemorySize could solve the problem, we'd <br>
> like to understand where the increase comes from. We already monitor <br>
> direct memory usage via BufferPoolMXBean, but it is not sufficient to <br>
> dig into the root cause. We really heap dumps to understand the root <br>
> cause.<br>
><br>
I don't have any objection to this. I only mentioned BufferPoolMXBean to <br>
show that memory for direct and mapped buffers is already exposed for <br>
monitoring purposes. Also direct buffers are a clear case where the <br>
memory is kept alive by live objects and at the same time have a runtime <br>
imposed limit. With the foreign memory API (Project Panama) it means <br>
there will also be memory segments that are part of lifecycles managed <br>
by memory sessions - in time, these will also be resources that may need <br>
to be monitored and maybe trigger heap dumps / OOME actions too.<br>
<br>
-Alan<br>
<br>
<br>
</blockquote></div>