4 ms·
What about shipping sun.misc.Unsafe as 3rd party package? Is there anything in it that can't be done as through JNI?
by karavelov 11y ago
What about shipping sun.misc.Unsafe as 3rd party package? Is there anything in it that can't be done as through JNI?
- snuxoll 11y agoNo, you can do everything in Unsafe via JNI, but that comes with all the disadvantages of JNI (including .dll's and .so's is not so easy for a fat-jar deployment).
- vardump 11y agoIt'd be unusably slow. "sun.misc.Unsafe" compiles in the instruction stream. JNI implementation would need to go through a complicated calling mechanism. I think it'd be up to 100x slower.
- karavelov 11y agoAt least in OpenJDK it is in fact implemented as a JNI package, so it is already going through the JNI calling convention: http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/9b8c96f96a0f/src/share/classes/sun/misc/Unsafe.java http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/9b8c96f96a0f/s...
- twic 11y agoThat code shows that it's implemented as native methods, but not necessarily as JNI - these could be VM intrinsics, like Object::getClass and so on. This is the native code for Unsafe: https://github.com/openjdk-mirror/jdk7u-hotspot/blob/master/src/share/vm/prims/unsafe.cpp https://github.com/openjdk-mirror/jdk7u-hotspot/blob/master/... It's certainly JNI-ish. Whether it is actually called via the JNI mechanism, i can't tell.
- vardump 11y agoI think these are a strong hint they're not truly JNI: Line 61: * <p> Most methods in this class are very low-level, and correspond to a * small number of hardware instructions (on typical machines). Compilers * are encouraged to optimize these methods accordingly. Line 90: /// peek and poke operations /// (compilers should optimize these to memory ops)