Java9 incompability

I think you missed the point :slight_smile:
They are not, instead on java9 a primitive allocator is used that cannot do any delete at all.
Also the interface is in place, to later write lwjgl and jogl native allocators, that then can cleanly do this using native code.

So in short this is mostly the creation of the interface, a simple noop allocator and one that is identically to the former behaviour, that will be used if the packages are reachable.

ho okā€¦ makes sense now :stuck_out_tongue:
Well it looks ok for me, but Iā€™d like to know @pspeed and @Momoko_Fan opinions.

Iā€™ll have to look later in more detail. Iā€™m not opposed to the concept of an interface.

ā€¦according to the automated build it seems broken, though.

https://travis-ci.org/jMonkeyEngine/jmonkeyengine/builds/143537975

Already fixed that right after, if you look athe the pull request, was from an leftover java8+ import.

oh cool! So now itā€™s possible to use jemalloc as allocator for all jME-Buffers?

Yes-no, I have done the foundation, but

once the pull request is merged, it is very easy to use any allocators that you can somehow use in a way to get Directbuffers.

If you manage to put in this interface, is is really easy to write the missing part (if you know how to use that allocator, it would be really nice if you could create one and maybe contribute it)

public interface BufferAllocator {
 
 	void destroyDirectBuffer(Buffer toBeDestroyed);
 
 	ByteBuffer allocate(int size);
 
 }

Hi,

as @zzuegg already said: lwjgl3 has jemalloc included. And its pretty easy to use. Here are some examples http://www.java-gaming.org/index.php?topic=36524.0
I already use jemalloc for my own game and I extensively use it for my vertex buffers to generate meshes.

2 Likes

Awaiting your pull request :innocent:

2 Likes

It seems, there is a bug in your PR. I cannot set another allocator because the flag ā€œusedā€ was already set to true after the static block was executed where the default allocator was set to ReflectionAllocator. The ReflectionAllocator allocates a ByteBuffer via BufferUtils which leads to calling the onBufferAllocated() method.

PR: https://github.com/empirephoenix/jmonkeyengine/pull/1

I just merged the request to mine, and now travis says that it does not find the jmeallocator stuff.
https://travis-ci.org/jMonkeyEngine/jmonkeyengine/builds/145141130
Does it need anything more to work correctly?

uhm hmm it seams that I have replaced the lwjgl.jar by the one from here LWJGL - Lightweight Java Game Library

I think the jme version of lwjgl.jar is outdated. Because the one from the website has ovr, vulkan and so on already included. So simply try to replace your lwjgl.jar with the new version. And donā€™t forget to update the natives => ā€œlwjgl-platform-natives-windows.jarā€

In case if it doesnā€™t work. My current libs: http://alrik-online.de/libs.zip

So yours is probably based on lwjgl3 and JME still (baseline) builds with lwjgl2.

Ok, so that jmallocator has to be moved to custom? lwjgl3 brnach whatever instead?

Little word, may worth nothing : service provider.
I only used that once, but the the basic idea is (quoted from the java doc) :

A service is represented by an abstract class. A provider of a
given service contains one or more concrete classes that extend
this service class with data and code specific to the provider.

http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Service%20Provider

It seems exactly what you are talking about, and it could avoid reflection (even if i think that there is reflection behind this api).

If this post was useless, forget about it and i am sorry :stuck_out_tongue:

You cannot use my source code in JMonkeyEngine because itā€™s under GPL v2. Empire_Phoenix is partially wrong because my deallocation helper doesnā€™t use sun.nio.ch.DirectBuffer unlike JMonkeyEngineā€™s equivalent. This is very important as the JEP 260 prevents the access to sun.nio.ch.DirectBuffer but not to sun.misc.Cleaner (in theory). The stack trace above shows that Java 1.9 fails on sun.nio.ch.DirectBuffer which confirms my claim.

Moreover, my deallocation helper is a lot more elaborated, it handles tons of cases JMonkeyEngine doesnā€™t :

  • support of 4 distinct JREs (OpenJDK/Oracle/Sun Java, Android Dalvik Virtual Machine, Apache Harmony and GNU Classpath)
  • support of all direct NIO buffers including sliced buffers and views
  • robust mechanism to adapt to naming changes

@Empire_Phoenix Run TUER (pre-beta version) before claiming that itā€™s broken too.

Edit.: Iā€™m going to try JDK 1.9 build 128.

Hi

My source code was working with Java 1.9 before some changes occurred. sun.misc.Cleaner has been moved to jdk.internal.ref.Cleaner and something more is necessary to be allowed to access this class.

Edit.: The command line switch to access this class without getting a
java.lang.reflect.InaccessibleObjectException is at the very last
paragraph of my answer on StackOverflow.

Edit2.: The best solution is in my post on SO, Iā€™ve just updated it, Iā€™ll update JMonkeyEngine when I have some spare time. No hack and no private API :slight_smile: just some reflection :wink:

Edit3.: Iā€™ve fixed my own source code and Iā€™ve tested it with Java 1.9 build 129. There is no need of adding any exports from java.base to our unnamed module. The very last solution in my post on SO works correctly. You just need to avoid using explicitly the class name of the cleaner by looking at the return type of the method cleaner() inside the direct NIO byte buffer and to call cleaner.run() if itā€™s a Runnable (it wasnā€™t a Runnable in Java 1.8). Enjoy :slight_smile:

@Empire_Phoenix TUER wasnā€™t broken, the exception was caught and the direct NIO buffers were no longer ā€œfreedā€. Now, the direct NIO buffers are freed with Java 1.9 too and my deallocation helper still uses a hugely different mechanism. This is still the most capable deallocation helper Iā€™ve seen, more cross platform, more reliable and much more tested.

Iā€™ve just fixed the reflection allocator of JMonkeyEngine 3, it now works with Java 1.9 too and it still works with Java < 1.9:
https://github.com/jMonkeyEngine/jmonkeyengine/commit/f820bbfd94c16021f8a360796ff499f0d1ce2d28

What worked with Java < 1.9 now works with Java 1.9. I tried to keep the source code as simple as possible. Itā€™s a compromise. In other words, it does NOT support tons of corner cases I treated in my own deallocator but the change list is quite short and it shouldnā€™t be a problem as it supports about the half of the kinds of buffers that you can create with BufferUtils. If the addresses of the direct NIO buffers are expected to be aligned but arenā€™t, BufferUtils.createFloatBuffer() will create a ByteBufferAsFloatBufferB or a ByteBufferAsFloatBufferL and the reflection allocator wonā€™t be able to destroy it.

There is still some room for improvement as the methods found at runtime only when using Java 9 arenā€™t cached yet.

Finally, there is no need of providing a JOGL specific allocator/deallocator, this one is enough, you can use it even though you donā€™t use the JOGL backend.

2 Likes