Buffer allocator implementation set by LwjglContext gets ignored sometimes


LwjglContext (in jme3-lwjgl3 module) specifies its own implementation of buffer allocator to be used by BufferAllocatorFactory by setting PROPERTY_BUFFER_ALLOCATOR_IMPLEMENTATION property in this static code block:

the issue is that sometimes this property gets ignored by BufferAllocatorFactory and a ReflectionAllocator is created instead. That is because BufferAllocatorFactory.create() method sometimes is called before the LwjglContext sets the new property. Inside the BufferUtils class:

Sometimes the order of these static code execution is different, e.g the one in the BufferUtils runs before the LwjglContext, which will cause BufferAllocator allocator to get initialized with Reflectionallocator and bypass the LWJGL3 allocator.

2 possible fixes are suggested for this issue:



I have also submitted an issue to GitHub:


We might have the same issue in android OGLESContext as well:

1 Like

The fix i proposed is similar to what the engine already uses for the backend support, for example, so i think we should go with that.

I will look into it, but first we need to get this merged


So should the current buffer allocators get renamed to NativeBufferAllocator?

For example, jme3-lwjgl3 has 2 native buffer allocators, LWJGLBufferAllocator and ConcurrentLWJGLBufferAllocator which extends LWJGLBufferAllocator. ConcurrentLWJGLBufferAllocator is used by default.
How do you want to rename these classes?

1 Like

Probably we should have NativeBufferAllocator as a third class that uses either LWJGLBufferAllocator or ConcurrentLWJGLBufferAllocator(default) depending on a system property that is passed from the command line

1 Like

To me, using a config file (e.g. bufferallocator.cfg) seems a bit cleaner.

For example in the jme3-lwjgl3 module the file will contain:


Then BufferAllocatorFactory will first check for a user-specified property using System.getProperty(PROPERTY_BUFFER_ALLOCATOR_IMPLEMENTATION) and if nothing is specified then it will check the bufferallocator.cfg file.

No extra wrapper classes.

1 Like

I am not sure, i think the other approach is cleaner, also easier to figure out if you are looking at the code for the first time and it is already used throughout the engine.

Regarding the wrapper class, if we think it through is it there even a reason to keep a non concurrent allocator? We should probably keep only the concurrent one.

Well in the future, we might add other allocators. For example, the JEP 419: Foreign Function & Memory API will introduce a new API that we can use to release direct byte buffer memory purely in Java so then using the name NativeBufferAllocator for this would not make sense also if we decided to make it the default for one of the backends. But using a config file we can just replace the string to switch the allocator.


Mhh, ok. I agree with your proposal.