As part of the preparation for JEP 260 [1], Unsafe needs to be separable
from the base module [2], so it can be exported by a new, yet to be
defined, jdk.unsupported module, and have a separate evolution policy
that is not exposed. That is, the JDK needs an internal Unsafe that can
be evolved and added to in future releases, while maintaining the
existing Unsafe API that developers are using.
Many uses of Unsafe are for performance reasons. Any changes made
should preserve the current performance characteristics. To achieve this
the existing Unsafe intrinsic candidate methods should remain intrinsic
candidate methods. The VM can provide aliases for these intrinsics so
they are common to both the internal and sun.misc versions of Unsafe.
The JDK implementation will be updated to use the new internal version
of Unsafe.
For the purposes of making progress, I think this work can be split into
several steps:
1) Create the new internal Unsafe class and provide intrinsic support
for both.
2) Update existing, and possibly add new, tests to use the new
internal Unsafe. Some tests may need to be duplicated, or reworked,
to test both versions of Unsafe.
3) Update the Unsafe usages in the JDK so that there is no longer any
dependency on sun.misc.Unsafe.
To this end I've put together a webrev containing the changes required
for step 1. It contains
- the intrinsic aliasing,
- the new internal Unsafe ( copy of sun.misc.Unsafe ),
- reverts sun.misc.Unsafe to, almost, its 1.8 API,
- minimal test and implementation updates, since there some usages
of unaligned access that is new in the 1.9.
http://cr.openjdk.java.net/~chegar/unsafe_phase1/
All JPRT hotspot and core libraries tests pass.
I have most of the work for steps 2 and 3 done, but some discussion and
clean up is required. It also increase the level of difficult to review
the changes in phase 1, which is mostly what I'd like to get agreement
on first.
-Chris.
[1] https://bugs.openjdk.java.net/browse/JDK-8132928
[2] https://bugs.openjdk.java.net/browse/JDK-8139891
