0

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?

Community
  • 1
  • 1
sdoca
  • 7,832
  • 23
  • 70
  • 127

2 Answers2

1

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

kosa
  • 65,990
  • 13
  • 130
  • 167
  • I read about the not being stable part on the SO question I linked to. Is that a reason not to enable it? – sdoca Nov 16 '12 at 17:09
  • @sdoca: By enabling it you won't loose any functionality, but whether this flag produces correct heap dump (or) not is not guaranteed. I guess you can enable in production systems also, but as Peter answered, you need to cleanup heap dump logs frequently, otherwise you may end up disk out of space. – kosa Nov 16 '12 at 17:10
  • Thanks. As per my comment on Peter's answer, we have the ability to clean up the dump files as needed. – sdoca Nov 16 '12 at 17:15
1

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.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • I'm confused by your comment that it's only useful for debugging/development. If we run into an OutOfMemory error in our production system, wouldn't we want that heap dump? – sdoca Nov 16 '12 at 17:07
  • 1
    Only if you have support of the developers of the software. Not all users of Java applications are in a position to analyse a heap dump e.g. applet users. – Peter Lawrey Nov 16 '12 at 17:11
  • We would be enabling this on JVMs that run enterprise software that we (my team) have written. We have full access to our servers including the ability to clean up the dump files as needed. – sdoca Nov 16 '12 at 17:15
  • In that case, it sounds like a good idea. I was trying to explain why it is not on by default. – Peter Lawrey Nov 16 '12 at 21:00
  • I'm accepting this answer because it more specifically answers my question, if there's any reason not to turn on this feature. – sdoca Nov 19 '12 at 17:13