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

[David Holmes]

Man Cao manc at google.com on Fri Sep 23 22:24:21 UTC 2022 wrote:
 > Thank you both for the feedback.
 >
 > > I realise the focus of JDK-8294052 has narrowed
 > > since it was created but I think it would be fair to say that it would
 > > probably require going through them case by case to see if it make 
sense.
 >
 > 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 there is a case for triggering a heap dump or doing the other
 > > OOME actions when a direct buffer can't be allocated.
 > > ...
 >
 > 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.

If all you really need is heap dumps then aren't there other ways to get 
those via the management API (that you are already using)?

I really do not want to turn these VM flags into an exported API for use 
by JDK code if it can be avoided (they are crude and basic and minimally 
tested). If that kind of functionality is needed then I'd prefer to see 
a JDK-side API to provide it in a cleaner, more supported way.

David
-----

 > -Man