Transilvania JUG

Sponsors

01
Mar
2014
6

Detecting (write) failures when using memory mapped files in Java

Memory mapped files are a good and often overlooked tool. I won’t go into the details here on how they work (use the force Google Luke!), but I will  quickly summarize their advantages:

  • lazy loading and write caching provided by the OS (you don’t have to write your own and it’s a safe bet that the OS’s one is well performing)
  • easy reading for complicated binary data (for example one which has all kind of relative offsets encoded in it)
  • can be used as a very high performance IPC mechanism
  • written to disk even if your process crashes (if the OS survives)
  • very high speed writes because you don’t block (the asynchronous flush is provided by the OS) and you don’t need to enter kernel mode

However with all this asynchronicity I was left wondering: what happens in case of a disk failure? How can the OS notify your process that it failed to write to disk what you’ve written to memory?

A little bit of searching turned up the answers:

  • Under Linux your process gets a SIGBUS when the OS tries to write the memory back to disk but fails
  • Under Windows you get an EXCEPTION_IN_PAGE_ERROR error the next time you try to call an OS function on the file handle

Wanting to confirm the information I whipped up a quick test program, plugged a sacrificial USB drive into my laptop and did a couple of tests. The conclusions are:

  • Sure enough Linux generates a SIGBUS and Java (OpenJDK 1.7.0_51-b00) has no handler for it, crashing the process:
    # A fatal error has been detected by the Java Runtime Environment:
    #
    #  SIGBUS (0x7) at pc=0x00007f9bb5042396, pid=26654, tid=140306951444224
    #
    # JRE version: OpenJDK Runtime Environment (7.0_51) (build 1.7.0_51-b00)
    # Java VM: OpenJDK 64-Bit Server VM (24.45-b08 mixed mode linux-amd64 compressed oops)
    # Problematic frame:
    # v  ~StubRoutines::jlong_disjoint_arraycopy

    On the upside you know that something went horribly wrong since your process ceased to be. On the downside you might not immediately way (unless you’ve read this post :-))

  • Linux can also generate more “traditional” error condition if you try to flush the file for example:
    Exception in thread "main" java.io.IOException: Input/output error
    	at sun.nio.ch.FileDispatcherImpl.force0(Native Method)
    	at sun.nio.ch.FileDispatcherImpl.force(FileDispatcherImpl.java:76)
    	at sun.nio.ch.FileChannelImpl.force(FileChannelImpl.java:376)
    	at Main.main(Main.java:84)
  • Windows only generates exceptions when you operate on the filehandle again (for example by flusing it – like in Linux – but also when creating new mappings – something not experienced in Linux):
    Exception in thread "main" java.io.IOException: The volume for a file has been externally altered so that the opened file is no longer valid
            at sun.nio.ch.FileDispatcherImpl.size0(Native Method)
            at sun.nio.ch.FileDispatcherImpl.size(FileDispatcherImpl.java:96)
            at sun.nio.ch.FileChannelImpl.size(FileChannelImpl.java:307)
            at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:849)
            at Main.main(Main.java:64)

Conclusion: memory mapped files are great – like a very sharp knife is great: you can do great things with them very quickly, but they can also cut your finger of. If you want to use memory mapped files because of the advantages they offer:

  • be ready to crash. Have a plan for when it will happen (hot standby, warm standby, do nothing – these are all valid options, but decide in advance)
  • if you want to be sure that the data is on the disk, flush it. When that returns you can (almost) be certain that the data is on disk (we won’t get into the wonderful world of disk / controller caches or virtualized servers here :-))

6 Responses to Detecting (write) failures when using memory mapped files in Java

  1. Would be interesting to see if you could register a signal handler for this in Linux on your own to prevent the JVM from crashing but providing at least an exception to the user :)

    Chris

  2. Philippe Marschall says:

    How do you deal with the fact that there is no way to unmap memory mapped files in Java?
    http://bugs.java.com/view_bug.do?bug_id=4724038

    • The “unofficial” way is to do the following: ((DirectBuffer) buffer).cleaner().clean();

      The official way is to wait for the GC, which will remove the DirectBuffer and also clean up the associate mappings. This is not always feasible though and can lead to OOM.

      To stay on the safe side, you should do your mappings on startup and don’t change them much during runtime.

      • Philippe Marschall says:

        In regards to the “unofficial” way the bug has the following to say

        This is highly
        inadvisable, to put it mildly.

        Waiting for the GC is not an option. You don’t know if this happens at all if ever. If you use the mapped file for a longer moment it will likely make it into old gen. If your GC and application is well tuned old gen may never be collected.

        So yes, doing the mappings on start up and never changing them seems like the only option.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>