Hey guys,
A few days ago I finished an InfoQ article about most of the proposals that laying around for Java 9 and beyond, mostly related to possible solutions for the eventually disappearing internal classes like sun.misc.Unsafe.
For interested people: http://www.infoq.com/articles/A-Post-Apocalyptic-sun.misc.Unsafe-World
Chris
PS: If malicious would’ve been the better sub-forum please move 
Hi
As sun.misc.Cleaner and sun.nio.ch.DirectBuffer are still available, I’m happy ;D
Seriously, I would be glad to work on a whole revamping of the NIO buffer API. I’ll look at the JEP 193. I don’t understand why the new arrays will support 64-bit indices but there is no such change planned for the NIO buffers. What will happen when we’ll try to wrap a brand new array 2.0 into a NIO buffer?
The problem is you cannot easily revamp the ByteBuffer APIs without breaking backwards compatibility, so I expect a new API to come up. It would be possible using default methods but it would look kind of awkward.
Btw are you sure about sun.nio.ch.DirectBuffer so far it is not part of the list (http://openjdk.java.net/jeps/260) and I haven’t fought for this one either 
- return (int) VERSION.addAndGet(this, 1);
+ return (long) VERSION.addAndGet(this, 1);
Uh right, thanks
I understand your position. Some Sun employees talked about performance concerns too, I don’t know if it’s still relevant.
This class is necessary to access the viewed buffer. You’re right, it’s not in the list 
I don’t think this is an issue and tbh I don’t think it ever was. My best guess for the int indexed methods is the BB backed by an array. Therefore you had a max of Integer.MAX_VALUE as an index, so why having long for ByteBuffers.
Not sure what you mean with “viewed buffer”
When you call ByteBuffer.asFloatBuffer(), it returns a view of this byte buffer as a float buffer. The “viewed buffer” is the byte buffer. There is no way to get this byte buffer from the float buffer without using sun.nio.ch.DirectBuffer. It’s used in my game and in JMonkeyEngine 3:
https://svn.code.sf.net/p/tuer/code/pre_beta/engine/renderer/ReliableRenderer.java
When the float buffer is created in a source code not under our control, we can’t just store the byte buffer somewhere during the creation of the view.
I see your point, kinda weird:
java.nio.DirectFloatBufferS/U do have an attachment method (both classes are package private but who cares ;-)) whereas ByteBufferAsFloatBufferB/L have a field called “bb” but no attachment method. However you can still retrieve the underlying buffer without sun.nio.ch.DirectBuffer.
Has anyone seen where the auto-vectorization (I previously said I thought IBM…but it was probably Intel) patch is at?
Yes, but it’s not very smart :clue:
Not sure which on you mean, you’re not talking about automatic GPU vectorization, do you?
Well no, it is as “un-smart” as using the sun class
No…plain old SSE/AVX simd.
Ah I see, ehm no idea actually. I remember I’ve seen something about it but I don’t think it went into the JDK 9 build (at least not yet).
thanks for the heads-up noctarius! nice to see there is an unsafe afterlife.
i’m wondering about the native memory access tho - if one would like to skip the bytebuffer classes altogether and just use allocateMemory, reallocateMemory, freeMemory and primitive accessors, do you think i should just go ahead and use JNI to recreate that functionality ? not sure if got your example right, but it looks like there is a intermediate primitive array, no ?
Yeah VarHandles are some kind of native arrays. It works like XBuffers (FloatBuffer, LongBuffer, …). If you need free access to all kinds of data, there is currently no such possibility / alternative. Also native memory allocation is not yet possible but I have a prototype implementation to wrap Unsafe::allocateMemory inside of the VarHandle static factory method. Still this is more like an single-type array access.
The best option at the moment might be JNA or JNR + jmalloc (http://hardcodejavadog.blogspot.de/2015/02/comparing-java-off-heap-memory.html) but still you always have to pay a little tradeoff since there are not custom intrinsics available (most Unsafe methods are intrinsified), but those are also on the roadmap for Java (eventually ;-)).
awesome, much appreciated!
My pleasure The work and time I put into convincing Oracle to not remove Unsafe without a replacement sold out in the end, that’s the only thanks necessary
but there is no other solution to release the native memory of the direct NIO buffer created with the standard API. What is really “un-smart” to me is the design of the current API which lets you create some direct NIO buffers but which provides no smart mean to “free” them. It’s impossible to do it without using the reflection API to access package protected classes, private fields and Sun internal classes… and it’s the case since Java 1.4.
I hope that you will succeed in providing another API because jemalloc and JNA aren’t an option for me.