Memory leak - is it my application or lwjgl?

[Andrew_3ds]

I was looking at the ram usage of my application and realized it was going up really fast, even doubled in size from when it just started after a few minutes. I spent some time commenting out code and figured out it was coming from uploading a Matrix4f to a shader.

Here is the code that is being used

public void loadMatrix(int loc, Matrix4f mat) {
        matBuffer = BufferUtils.createFloatBuffer(16);
        mat.store(matBuffer);
        matBuffer.flip();
        glUniformMatrix4(loc, false, matBuffer);
        matBuffer.clear();
    }

I don't know if the memory leak is coming from the buffer itself or the buffer getting stuck somewhere in the native calling and never deleted.

[Neoptolemus]

Have you tried using a memory profiler? It will tell you which object types are eating up the most memory.

I did notice that you clear the buffer at the end, but then reinitialize it with a new FloatBuffer instance at the start anyway. You can remove the first line and just initialize matBuffer once somewhere else, see if that helps.

[Cornix]

What operating system do you use and what drivers are installed?
I know for a fact that some outdated driver versions are bugged and leak memory.

[abcdef]

Try not creating a new FloatBuffer every method call, either have one you re use every time in the class with this method or have Matrix4f have one itself (assuming you don't create mat from scratch every time)

[Andrew_3ds]

Try not creating a new FloatBuffer every method call, either have one you re use every time in the class with this method or have Matrix4f have one itself (assuming you don't create mat from scratch every time)

This fixed the problem. Deleted that line of code and the problem was fixed. Thanks.

[Neoptolemus]

Glad you fixed your issue  to be honest, it probably wasn't a memory leak, as those FloatBuffer objects you were creating would have been marked for garbage collection once matBuffer was reassigned since they're not referenced anywhere else in the program.

Depending on how much RAM you have and how much is assigned to the JVM, it was probably just letting them pile up for a bit before clearing them later on. Of course the issue then is you might start getting regular hitches or framerate drops each time the GC runs, given the large heap of memory it has to clear, so it's always best to avoid creating too many throwaway objects like that.