Reading this thread as C programmer has me scratching my head.

Of course you have to resort to low-level functionality to achieve performance. That's how computers work. We can't all live in fuzzy wuzzy land.

Surely Unsafe is safer than writing the whole thing in C and using JNI?

I completely agree - I have no problem with leveraging low-level functionality, but there's usually a safe and and unsafe way to approach it - and from what I've read 'unsafe' doesn't take the secure approach.

(separately: why the downvote? I get downvoted for having the opinion that it's worth a tiny bit of performance for improved security?)

Yes. Also there are many "safe" operations on "unsafe". Such as memory fences.

Multithreading is somewhat unsafe in general. And so is ability to do most I/O, you might overwhelm the system.

Sure. Unsafe in terms of program correctness. By that measure, new Thread() is unsafe.

But that's not a reasonable definition of "unsafe". This could crash the JVM is a reasonable definition. And fences and ordered instructions cannot.

This sort of practice is present in the implementation of every mainstream programming language. 'Unsafe' operations are the bread and butter of computation.

As far as use in libraries, you wont get the same performance without it in most of the places it is used. This is much like Python's 'unsafe' use of C modules for performance.

As a corollary, many Java programs rely really heavily on very thick layers of abstraction (in my day-to-day on a multi-node "enterprise" Java app I regularly see stack traces of 200-500 function calls), and it's important to keep each slice of those abstractions as thin as possible.

As another reply pointed out, much better to do some hinky things with the JVM then to call out through the native interface every time you need high performance for a tight loop.