> (i tried to type "segfault" instead of "default" before autocorrect mangled it). (Ah. If only the dictionaries were bigger..... sigh) > The most common sign

> (i tried to type "segfault" instead of "default" before autocorrect mangled it). (Ah. If only the dictionaries were bigger..... sigh) > The most common signals you get in this situation are SIGSEGV and SIGBUS. AFAIK you can't catch it in Java. I just had a look around, and it seems you're unfortunately right. - http://stackoverflow.com/questions/39183517/java-8-application-using-all-of-system-ram-and-then-crashing-with-a-sigbus-what http://stackoverflow.com/questions/39183517/java-8-applicati... - https://forums.macrumors.com/threads/java-catching-stack-overflow-sigbus-error.99812/ https://forums.macrumors.com/threads/java-catching-stack-ove... - Apple appears to have taken responsibility for one, but I don't think mmap was involved: https://lists.apple.com/archives/java-dev/2002/Aug/msg00129.html https://lists.apple.com/archives/java-dev/2002/Aug/msg00129.... (found in the above link) It kind of makes sense, the JVM pretends it's the "world", so something platform-specific affecting that world is generally going to be treated as a literal end-of-the-world (pun genuinely not intended... lol). But then there's JNI. So Java does acknowledge that the OS is kind of there. And not all signals are fatal! This is mildly stupid. > You can get these errors in circumstances that don't involve physical IO device errors, you can also get them in cases where the OS decides you can't get to that file (eg another process truncates it, or you run out of space writing to a sparse file, etc). Oooh, riiight. Because you're not doing read()/write() I/O and mmap() is memory-centric, the kernel treats failures as memory errors. Makes a lot of sense!! > By proper use of read() i meant being performance conscious. read() will usually have to copy the data into your buffer, whereas mmap() can just give you a virtual-memory assisted view of the kernel buffer cache. To eliminate this as a source of slowdown, you should size the read buffer so that it fits in CPU cache but still results enough work per read() call that the system call overhead doesn't get you. Around 128k is often close to the sweet spot. Oh, it's because of cache consistency! I get it now! I remember reading an article on here very recently about exactly this, but I can't remember any terms it had in it so I can't find it :(