Reputation: 8042
I've recently learned about the -XX:+HeapDumpOnOutOfMemoryError
VM argument and was told that it should be added as a matter of course to the HotSpot JVM as it is off by default. One of my co-workers made a comment that maybe we shouldn't because he heard that there's some pitfall to doing this but he can't remember what it was. I hate vague statements like that, but am trying to do my due diligence before making a final decision so am doing some investigation.
Most of the references to it I can find are more about how to use it (and where the dump files are located) and don't speak to any issues with using it. This SO question refers to a different argument, but the answers seem relevant to this one as well and imply that there are no issues: Why is this Hotspot JVM option not the default? -XX:+PrintConcurrentLocks
Does anyone know of any reason not to turn -XX:+HeapDumpOnOutOfMemoryError
?
Upvotes: 1
Views: 2170
Reputation: 66637
With this particular flag I don't think any issues (Don't know about other flags). This is not even a diagnostic flag. It just prints GC/Memory state when JVM encounters OutofMemoryError (happens only once and that too while JVM stop).
One thing you need to accept is, it may (or) may not behave as expected, because it is -XX and
Options that are specified with -XX are not stable and are subject to change without notice
Upvotes: 1
Reputation: 533520
The main downside is that it creates a large file the each time a new program getting this error (the first time it happens for that JVM). If you have a heap of 2 GB, it could create a file that big each time, filling up disk space with heap dumps you don't need. Since its only useful for debugging/development purposes, it not useful for most end users.
Upvotes: 2