Oracle software engineer Paul Sandoz posted a message on the OpenJDK mail list and sent a tweet last week asking the public to weigh in on the library sun.misc.Unsafe by responding to a Survey Monkey survey.
The debate centers around whether pieces of Unsafe should be mainstreamed. The controversial class is under scrutiny due to its divergence from the Java credo of safe memory management.
sun.misc.Unsafe has over 100 methods, in categories such as synchronization, direct memory access, object and member manipulation, and other categories antithetical to the Java credo of safe memory management. Some of these methods such as volatile reads and writes, ordered writes and compare-and-swap operations are heavily used by the java.util.concurrent libraries.
According to the Java doc, Unsafe contains "A collection of methods for performing low-level, unsafe operations. Although the class and all methods are public, use of this class is limited because only trusted code can obtain instances of it."
For a "quick overview of sun.misc.Unsafe public API and few interesting cases of its usage." refer to Mykhailo Kozik's blog on the topic.
The survey questions are:
- Have you ever used the Java class "sun.misc.Unsafe"?
- What project(s) did you use Unsafe for?
- What methods on Unsafe did you use?
- What reasons did you use Unsafe for? Responses include:
- Atomic access to fields and array elements (such as compare-and-swap)
- Off-heap memory operations (such as to emulate structures or packed objects)
- Deserialization hacks
- Fencing (to constrain re-ordering of memory operations)
- Access to private fields of another class
- Array access without bounds checks
- Other (please specify)
- What features (if any) are missing from Unsafe?
- Do you have an optional dependency on Unsafe to ensure code is portable across multiple Java platforms?
- If there was a "safe unsafe" standard (cross-platform) alternative for your use-cases (perhaps a new API, perhaps language changes, or both) would you be prepared to replace Unsafe with that alternative? If so under what conditions?
In addition to soliciting community response to determine usage metrics, Sandoz says Oracle is also planning to "trawl stuff on repos."
The low-latency world seems particularly passionate about the topic. Peter Lawrey is Principal Consultant at Higher Frequency Trading Ltd. and lead developer of the low-latency OpenHFT libraries. He told InfoQ:
While Unsafe should be hidden from most developers and most of the code, it provided some particularly useful low level, thread safe access to memory which is more efficient than JNI calls. i.e. there really is no other way to do what Unsafe does efficiently. What we need is a replacement which is standard across JVMs and can be extended for newer technologies such as Hardware Transaction Memory e.g. Intel TSX.
Ben Cotton, an active member of the Mechanical Sympathy low-latency community forum, told InfoQ:
FUD (and, frankly, outright technical bigotry) results when the only route to the most complete memory allocation management capabilities is exposed through a package named 'Unsafe'. As proposed by the new JEPs for Off-Heap and FFI (Foreign Functional Interface), let's get rid of this awful name and instead promote the competent (and thus safer) usage of this package as a means to solve important Java performance problems;
Christoph Engelbert solution architect at Hazelcast, the popular open source in-memory data grid vendor told InfoQ:
A public API with the feature set of sun.misc.Unsafe will be for Java 9 what Lambdas is for Java 8 - not as commonly used but just as important. Apache DirectMemory and Lightning as well as Hazelcast heavily using sun.misc.Unsafe for speeding up serialization, memory access and lowering pressure on the Garbage Collector (with off heap data structures). It is a must have feature!"
According to Sandoz the survey will close on Feb 7, 2014.