Should OutOfMemoryError from NIO direct memory honor JVM flags for handling OOME?

[Man Cao]

>
> I don't have any objection to this. I only mentioned BufferPoolMXBean to
> show that memory for direct and mapped buffers is already exposed for
> monitoring purposes. Also direct buffers are a clear case where the
> memory is kept alive by live objects and at the same time have a runtime
> imposed limit. With the foreign memory API (Project Panama) it means
> there will also be memory segments that are part of lifecycles managed
> by memory sessions - in time, these will also be resources that may need
> to be monitored and maybe trigger heap dumps / OOME actions too.


Great! Thanks for the feedback. I'll proceed with the RFR.

+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.

-Man



On Sun, Sep 25, 2022 at 1:10 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 23/09/2022 23:24, Man Cao wrote:
> > :
> >
> > Yes. I completely agree that the OOMEs should be analyzed case by case.
> > Also completely agree that the OOMEs for large array allocations do
> > not need to handle these JVM flags.
>
> I think OOME has been over used and if we could go back in time then
> maybe things would be different and OOME would not be thrown for some of
> these cases.
>
>
> > :
> >
> > It sounds like I could proceed sending the RFR to support these JVM
> > flags for direct memory OOME?
> > In our case, the application sets -XX:MaxDirectMemorySize and it ran
> > out of this limit.
> > While bumping up MaxDirectMemorySize could solve the problem, we'd
> > like to understand where the increase comes from. We already monitor
> > direct memory usage via BufferPoolMXBean, but it is not sufficient to
> > dig into the root cause. We really heap dumps to understand the root
> > cause.
> >
> I don't have any objection to this. I only mentioned BufferPoolMXBean to
> show that memory for direct and mapped buffers is already exposed for
> monitoring purposes. Also direct buffers are a clear case where the
> memory is kept alive by live objects and at the same time have a runtime
> imposed limit. With the foreign memory API (Project Panama) it means
> there will also be memory segments that are part of lifecycles managed
> by memory sessions - in time, these will also be resources that may need
> to be monitored and maybe trigger heap dumps / OOME actions too.
>
> -Alan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20220926/5b615b0e/attachment.htm>