Hi
sun.nio.ch.DirectBuffer is used here but it’s not mentioned in the JEP 260 unlike sun.misc.Cleaner. Maybe we should contact the OpenJDK contributors so that they plan to keep it accessible in Java 1.9. What’s your opinion about that?
Hi
I suggest to use java.nio.DirectByteBuffer where it is possible (to get the cleaner) and look for the viewed buffer in the field “bb” and in the implementation of the method “attachment” or “viewedBuffer” (java.nio.DirectByteBuffer, java.nio.DirectByteBufferR, java.nio.DirectCharBufferRS, java.nio.DirectCharBufferRU, java.nio.DirectCharBufferS, java.nio.DirectCharBufferU, java.nio.DirectDoubleBufferRS, java.nio.DirectDoubleBufferRU, java.nio.DirectDoubleBufferS, java.nio.DirectDoubleBufferU, java.nio.DirectFloatBufferRS, java.nio.DirectFloatBufferRU, java.nio.DirectFloatBufferS, java.nio.DirectFloatBufferU, java.nio.DirectIntBufferRS, java.nio.DirectIntBufferRU, java.nio.DirectIntBufferS, java.nio.DirectIntBufferU, java.nio.DirectLongBufferRS, java.nio.DirectLongBufferRU, java.nio.DirectLongBufferS, java.nio.DirectLongBufferU, java.nio.DirectShortBufferRS, java.nio.DirectShortBufferRU, java.nio.DirectShortBufferS and java.nio.DirectShortBufferU).
It’s obviously less smart but it works with Java 1.5, 1.6, 1.7, 1.8 and 1.9.
I would prefer to use the directbuffer allocators of LWJGL3 then.
As they allow to properly be disposed without any dirty hacks.
At first, jme3-core can’t depend on jme3-lwjgl3. Secondly, those direct buffer allocators don’t support Android as far as I know.
Moving the responsibility of the native memory release into the backends is possible, Android can still simply call this method like today but the other backends for the desktop environments still need a default implementation not depending on jme3-lwjgl3 except jme3-lwjgl3 itself of course.
I’ll implement my suggestion in the other projects on which I work, feel free to remind me to do the same for JMonkeyEngine when there is a consensus about it.
I honestly never liked the idea of having this class the way it was designed.
I think an allocator/buffer interface would be the right way to go with this. As this would allow to use the best possible solution in different contexts.
I kind assume that jogl has some kind of native allocation system as well right? Then this could be used with the jogl context, wich would make more sense.
Having the core depend on some ugly reflection hack and jvm internals is not a good solution. (and never was). Prior there were no alternatives to this, but now we have them, and should evaluate their use.
I think that the whole dispose functionality is not stable possible without using internal jvm stuff or a library. So the default context should just get an not supported exception and done.
I guess that we could do something like URA and just have an interface that abstracts what is done under the hood on different back ends.
@Momoko_Fan what do you think?
The project Panama will (perhaps) provide another API to manipulate the native memory. In the meantime, there is no alternative to release the native memory of the direct NIO buffers created with the standard JavaSE API. JogAmp is going to remove the very last reference to sun.misc.Unsafe but its APIs are designed to allow the developers to use their own deallocators.
BufferUtils.destroyDirectBuffer is more of a hint than anything… Its designed to work on many JVMs, but by definition, cannot work on all of them, as it relies on JVM specific functionality.
I know that but it’s possible to make it work with Java 1.9 with a few (ugly…) changes. Actually, the implementation of this method is a lot more simple and faster than mine but it doesn’t find the viewed byte buffer when the class doesn’t implement sun.nio.ch.DirectBuffer, for example with ByteBufferAsFloatBufferL.
I’ve succeeded in implementing something robust with a fast path for known implementations and a slow path heavily using the reflection API. It works under Android too:
http://sourceforge.net/p/tuer/code/HEAD/tree/pre_beta/engine/misc/DeallocationHelper.java
There is no satisfying way to do it, “freeing” sliced buffers is still dangerous.