What are our middleware sun.misc.Unsafe uses?
With the removal of the "private" sun.misc.Unsafe api on the horizon, we need to document the uses we have for the Unsafe apis and ensure there are public replacements in Java 9/10. The current view is that although sun.misc.Unsafe may not be visible by default in Java 9, there will be a flag that enables access to the class to avoid an immediate need to avoid disruption when Java 9 releases.
The attached document is a summary of concerns that were raised by members of the Java Executive Committee(EC), and there was discussion around creating an EC working group to address this problem.
I have pulled together the following comments from Jason, David and Andrew. Please post the specifics of APIs we are using and why so I can start tying together the use case with
Jason Greene:
*Everything* in Unsafe is useful. It is the only way to do the things it does, and to abuse the idiom, whats necessary for the goose (JDK API implementations) is necessary for the gander.
Another use case is serialization. Without Unsafe or its Reflection internal API cousins, there is no way to implement a serialization framework with the same capabilities as Java serialization (e.g. the ability to serialize a class WITHOUT a public no-arg constructor).
DML:
One interesting note is that an Oracle employee was able to develop a
version of the Atomic*FieldUpdater classes which had performance on par
with Unsafe itself. The trick is to generate a new *Updater subclass
for each updater, which internally uses Unsafe. Because most of the
implementation methods in this case degenerate to straight calls to
Unsafe with constant arguments (without all the complicated access
checks that make these things slow), most of the additional cost
disappears, other than having the virtual method dispatch. I vaguely
recall that this might even be mitigated in an existing or future
hotspot version under certain circumstances: if you assign your updater
to a static final field, then the exact type of that field's value
should always be statically known to hotspot and thus it should be able
to optimize and even inline method calls on that reference. (If this
isn't the case, then, well, it ought to be... )
I do know that the performance results were quite good. I would
personally be reasonably satisfied with this solution in lieu of Unsafe
(at least for CAS field accesses). It doesn't do anything to address
the other use cases though - like atomic memory access for example,
which is a fairly important use case.
Andrew Haley:
I don't think that there are any real long-term reasons to keep
Unsafe. They are being addressed by things like VarHandles, my own
work on speeding up heap ByteBuffers so that they're as fast as C
arrays, and so on.
TODO:
| Project | Unsafe Usage | Replacement |
|---|---|---|
| jboss-modules | Low level primitives for synchronization | Usage will be dropped in 1.5 release when jdk7+ is required |
| infinispan | ADDRESS_SIZE, ARRAY_OBJECT_INDEX_SCALE | TBD |
| infinispan | compareAndSwapInt/Long, objectFieldOffset, get/putObjectVolatile, arrayBaseOffset, ConcurrentHashMapV8 backport from JSR166 | TBD |
| netty | ConcurrentHashMapV8,CountedCompleter,ForkJoinPool,Striped64 JDK8 backports from JSR166, copyMemory, arrayBaseOffset, objectFieldOffset, get/put/{Byte,Short,Int,Long} | TBD |
aesh | sun.misc.Signal* | No longer in use after 33.xx branch |
Imported Project Usage
| Project | Usage | Replacement |
|---|---|---|
| Apache Avro | Serialization | TBD |
| Guava | Striped64 backport from JSR166, arrayBaseOffset, getLong |
-
sun.misc.Unsafe - Version 2.pdf 233.9 KB
