Lowering garbage creation - Update with JSR-231

OpenGL Development JOGL Development
#1

You may remember my previous post abour garbage creation
http://www.java-gaming.org/forums/index.php?topic=10837.0.

One of the answer was that part of the generated garbage will disapear with the JSR.

I have now moved to JSR beta 1 and run a memory profiling. It appears that it is worst than before ; all functions like glVertexPointer now call checkArrayVBODisabled which call checkBufferObject which creates an int[1] (16 octets) each time in order to make a call to glGetInteger.

When this is multiplied by the number of batches times the number of arrays, it ends up creating quite a lot of garbage per frame.

This could be easily solved by having a function like the one in LWJGL ;

private static final IntBuffer int_buffer = BufferUtils.createIntBuffer(16);

/**
 * Obtain a GL integer value from the driver
 *
 * @param gl_enum The GL value you want
 *
 * @return the integer value
 */
public static int glGetInteger(int gl_enum) {
	GL11.glGetInteger(gl_enum, int_buffer);
	return int_buffer.get(0);
}

Or this could be optimized in the internals of the com.sun.opengl.impl.GLImpl.checkBufferObject method.

             Vincent

Note : for people interested, I have tried both options stated in my previous post (lowering garbage creation & managing part of my memory directly from java). I ended up using the second option with a simple implementation of object pools + reference count + pre-allocation profile. It gives very good result and have very little impact on the overall library design. Lowering garbage collection as a general rule was very difficult to implement whithout degrading the quality of the library (mainly cache & synchronization problems).

#2

Feel free to file a bug about this. In practice however I don’t think this allocation of garbage will have any measurable impact on performance.

#3

Please note that the above mentioned glGetInteger wrapper is not thread safe. So a general solution have to use either a monitor or a thread local buffer.

  • elias
#4

The underlying OpenGL method is not thread safe. In fact, all OpenGL is not thread safe. A library that wants to allow multithreading, like Java3D, has to monitor access to the underlying native library (OpenGL / DirectX) but this is not the work of the wrapper (it is more efficient to perform synchronization at a higher level).

Therefore, there is no need for a monitor or thread local buffer since this is just a wrapper around a non-thread safe function.

          Vincent

Note : I have filled an enhancement issue : https://jogl.dev.java.net/issues/show_bug.cgi?id=180

#5

This is not correct. It is legal to perform OpenGL calls concurrently from two theads if each has an independent OpenGL context current to it. The solution to this problem is simple; a per-context, single-element int array.

#6

Unfortunately this is allocateDirect, which means a bit more complication for gc (phantom reference, delayed collection, etc), plus two extra trips to native code. I think that correctly misdesigned microbenchark will be able to measure some difference in speed :slight_smile:

#7

In JOGL glGetIntegerv accepts non-direct IntBuffers which don’t incur these overheads. Additionally the variant taking an int[] as argument is still present.