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

David Holmes david.holmes at oracle.com
Tue Sep 27 07:21:46 UTC 2022


On 27/09/2022 3:31 am, Alan Bateman wrote:
> On 26/09/2022 08:35, David Holmes wrote:
>> :
>>
>> 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.
> 
> We added the built-in heap dumper and HeapDumpOnOutOfMemoryError in JDK 
> 6 to help with post mortem diagnosability of OOME. They have been 
> supported and documented (e.g. troubleshooting guide) and there are 
> several tools that support reading the .hprof format. It may be 
> rudimentary but the option to enable it seems to be widely used.

This is the way I see things (and I'm taking a bit of "poetic license" 
here). The Java language provided the OOME to report Java OOM 
conditions, but didn't provide the diagnostic tools to help with 
understanding the origins/causes. So we provided a mechanism in the VM 
to help with this. And yes there are also some Java-level tools to give 
some aid here. But people also want to diagnose other resource 
allocation failures, and again there are no diagnostic tools to assist 
them. So the natural first reaction is "hey lets just make this VM OOM 
stuff work for this situation as well". My reaction is "hey, maybe the 
JDK should be providing a more structured/consistent/supported mechanism 
for getting diagnostics for arbitrary resource allocation failures?". 
Obviously the VM has to hook into that - and arguably what the VM should 
be doing is just calling back up to Java to allow it to execute a 
registered callback that can do whatever is needed based on some 
diagnostic properties.

I'd much rather see a well-designed resource allocation failure 
diagnostic framework added to the JDK, than crudely provide a 
JVM_OnAllocationFailure method that then examines the various VM flags.

Cheers,
David
-----


> Yes, you can use the management APIs and BufferPoolMXBean to monitor the 
> use of direct memory and use the HotSpotDiagnosticMXBean "dumpHeap" 
> operation to generate a heap dump at any time. You can use another 
> HotSpotDiagnosticMXBean operation to enable the 
> HeapDumpOnOutOfMemoryError at runtime but it's not going to trigger if 
> the OOME is triggered trying to allocate direct memory.
> 
> I don't know if you have a JDK-specific API in mind but I think the 
> discussion here is about having a way to trigger a heap dump (and maybe 
> other OOME actions) when allocating direct memory fails.
> 
> -Alan


More information about the nio-dev mailing list