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

[Alan Bateman]

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