5 ms·

Unsafe lets you manipulate memory without any JNI overhead other than when allocating or de-allocating memory, and that is usually done in larger chunks and poo

by sreque 7y ago

Unsafe lets you manipulate memory without any JNI overhead other than when allocating or de-allocating memory, and that is usually done in larger chunks and pooled to avoid the overhead at steady state. Netty also takes advantage of Unsafe to move a lot of memory operations off the java heap. Unsafe was one of the cooler aspects to Java that Oracle is actively killing for, well, no good reason at least.

kllrnohj 7y ago
> Unsafe was one of the cooler aspects to Java that Oracle is actively killing for, well, no good reason at least. I mean, there's the obvious reason that it breaks the memory safety aspect that Java in general guarantees. The whole point of the feature is to subvert the language & expectations. I'm not saying they should remove it, but it's pretty hard to argue there's "no good reason" to kill it, either. It is, after all, taking the worst parts of C and ramming it into a language that is otherwise immune from that entire class of problems.
jayd16 7y ago
C# seems to have a neat middle ground for this kind of stuff with their Span<T> api.
- to11mtm 7y ago
  True, but we had our own version of unsafe for a much longer time. MS was just pragmatic enough to allow it across the ecosystem. I'm guessing at least some of that was a side effect of wanting to support C++; not having pointers as an option would have killed C++/CLI from the get go.
thu2111 7y ago
They aren't killing it. They're steadily designing safe and API stable replacements for its features, with equal performance. That is a very impressive engineering feat! For instance fast access to un-GCd off heap memory is being added at the moment via the MemoryLayout class. Once that's here apps that upgrade won't need to use Unsafe anymore. MemoryLayout gives equivalent performance but with bounds checked accesses, so you can't accidentally corrupt the heap and crash the JVM. They've been at it for a long time now. For instance VarHandle exposes various low level tools like different kinds of memory barriers that are needed to implement low level concurrency constructs. They're working on replacements for some of the anonymous class stuff too.
pjmlp 7y ago
Unsafe is being replaced by less error prone APIs, not killed. Project Panama is what is driving that effort.

by sreque 7y ago

kllrnohj 7y ago

> Unsafe was one of the cooler aspects to Java that Oracle is actively killing for, well, no good reason at least. I mean, there's the obvious reason that it breaks the memory safety aspect that Java in general guarantees. The whole point of the feature is to subvert the language & expectations. I'm not saying they should remove it, but it's pretty hard to argue there's "no good reason" to kill it, either. It is, after all, taking the worst parts of C and ramming it into a language that is otherwise immune from that entire class of problems.

jayd16 7y ago

C# seems to have a neat middle ground for this kind of stuff with their Span<T> api.

to11mtm 7y ago
True, but we had our own version of unsafe for a much longer time. MS was just pragmatic enough to allow it across the ecosystem. I'm guessing at least some of that was a side effect of wanting to support C++; not having pointers as an option would have killed C++/CLI from the get go.

thu2111 7y ago

They aren't killing it. They're steadily designing safe and API stable replacements for its features, with equal performance. That is a very impressive engineering feat! For instance fast access to un-GCd off heap memory is being added at the moment via the MemoryLayout class. Once that's here apps that upgrade won't need to use Unsafe anymore. MemoryLayout gives equivalent performance but with bounds checked accesses, so you can't accidentally corrupt the heap and crash the JVM. They've been at it for a long time now. For instance VarHandle exposes various low level tools like different kinds of memory barriers that are needed to implement low level concurrency constructs. They're working on replacements for some of the anonymous class stuff too.

pjmlp 7y ago

Unsafe is being replaced by less error prone APIs, not killed. Project Panama is what is driving that effort.