At first I’d like to thank all guys of JME, I used JME for my thesis of Master degree to show my algorithm. The problem is that I have a big array of Meshes:
public void plotLine() {
all_meshes = new Mesh[mainFParent.allData.all_Ways.length];
Geometry all_geo[] = new Geometry[mainFParent.allData.all_Ways.length];
int[][] indexes = new int[mainFParent.allData.all_Ways.length][];
for (int i = 0; i < all_meshes.length; i++) {
indexes[i] = new int[mainFParent.allData.all_Ways[i].myNodes.length * 2];
for (int j = 0; j < mainFParent.allData.all_Ways[i].myNodes.length - 1; j++) {
indexes[i][2 * j] = (j);
indexes[i][2 * j + 1] = (j + 1);
}
all_meshes[i] = new Mesh();
all_meshes[i].setMode(Mesh.Mode.Lines);
all_meshes[i].setBuffer(VertexBuffer.Type.Position, 3, BufferUtils.createFloatBuffer(mainFParent.allData.all_Ways[i].lines));
all_meshes[i].setBuffer(VertexBuffer.Type.Index, 2, indexes[i]);
all_meshes[i].updateBound();
all_meshes[i].updateCounts();
all_geo[i] = new Geometry("line", all_meshes[i]);
Material mat = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
mat.setBoolean("VertexColor", true);
all_meshes[i].setBuffer(VertexBuffer.Type.Color, 3, mainFParent.allData.all_Ways[i].color);
all_geo[i].setMaterial(mat);
rootNode.attachChild(all_geo[i]);
}
}
Above code initialize a global array of Meshes and it’s only called in “simpleInitApp”.
In each iterate of the algorithm:
public void refresh_color() {
for (int i = 0; i < all_meshes.length; i++) {
all_meshes[i].clearBuffer(VertexBuffer.Type.Color);
all_meshes[i].setBuffer(VertexBuffer.Type.Color, 3, mainFParent.allData.all_Ways[i].color);
}
}
The colors are refreshed elsewhere and here it’s fed into renderer by “app.enqueue”.
But the problem is that each time “refresh_color()” heap memory is increased a bit but after some time garbage collector clears heap but out of heap memory still increases. I used Netbeans profiler, see the results:
After reading your post, I’m not entirely positive what your issue is. Is your problem that heap usage is inexplicably increasing, or that the heap is significantly larger than is actually in use?
For performance (and garbage collection) reasons, the JVM always pre-allocates heap space. You should always see a difference between allocated heap space and used heap space, and often the difference will be large.
Used heap space is less than actual used memory space (I’ve read in another post that normally JME uses out of heap memory but it seemed to be for physics library mostly) and also “Out Of Heap” memory or unsafe memory access increases by calling “refresh_color()” method and it can completely crash computer. This means that some resources are allocated but not released well. Hardly it can cause computer crash, most of the times java virtual machine crashes if it continues, but it could crash computer in few times. Also heap space usage is normal, the average increase in periods is for the algorithm and a manual garbage collection calling can resolve it, but calling GC has no impact on actual memory usage, totally it should not affect it maybe because it’s VM memory but why out of heap memory increases recklessly, what I have missed? any solution to resolve it? It seems to be buffer problem but I have no idea how to handle such problems, where to seek for leakage, should I remake Meshes again each time?
In that case I’ll have to defer to someone more knowledgeable on how jME deals with off-heap memory. I’ve done very little relating to that, so I’m not sure how to diagnose or resolve the issue.
Well I don’t have RGBA and the 3 in “setBuffer(VertexBuffer.Type.Color, 3, mainFParent.allData.all_Ways[i].color);” resembles RGB I think, also the output is ok, do you think that I have to make it vec4? https://1drv.ms/i/s!AvJPXkrvjtdigSqdVbglvPTWPv1t
Also the problem shows itself when the number of Meshes be large such as 300,000.
An Important factor for rate of leakage or strange memory usage depends on camera view, more mesh rendering, more leakage. If the camera be zoomed leakage amount is reduced significantly. Maybe more evidence can be found in cull hint process. Also the JME part is inside SWING GUI. Maybe the problem is related to AWT canvas. Still trying and couldn’t find anything useful. Netbeans memory profiler shows nothing usable as things goes well inside heap memory.
/**
* Deletes all previously used {@link NativeObject Native Objects} on this Renderer, and
* then resets the native objects.
*
* @see #resetGLObjects()
* @see NativeObject#deleteObject(java.lang.Object)
*/
public void cleanup();
Random stuff to tack onto this thread in case it’s useful…
Things like meshes and textures, etc. in JME use direct memory instead of heap memory. Direct memory IS cleaned up during System.gc() but won’t trigger an automatic GC if you start running out of it.
For lots of reasons, it’s better to reuse your mesh buffers if you can.
You can generally store whatever you want in the mesh vertex buffers. It just depends on how you create them and what the shader expects. But for example, a color buffer can easily take 3 components or four. If the shader is expecting the fourth component to be alpha then it might render as transparent if you only pass vec3 to it.
renderer.cleanup() is meant to be called during shutdown, I guess. Edit: at least of that renderer… if you are calling it once per frame then that’s probably a bad idea. Generally, I wouldn’t expect any JME object to be usable anymore after calling its cleanup() method. It’s JME’s equivalent of “terminate”.
Many thanks @pspeed .
Well System.gc() doesn’t work as I test now and used it in the IDE profiler (trash can icon) many times.
Yes reusing mesh buffers helps much, I reuse them.
The problem maybe refers to programming stuff in GPU, I don’t know but something like the int address coming back from shader program. So, renderer.cleanup() is the only solution for my case now. As I said, the number of geometries which are shown in the screen affects the rate of out of heap memory leakage. Again I have no idea but it seems to be something like that, when the buffers are getting cleared and refilled, the renderer is still rendering old buffers so the renderer doesn’t free parts of them. Maybe I should stop rendering, change buffers then start rendering process again.
Also hopefully I used JME for GIS works not games so I don’t need frame rate. Also renderer.cleanup() is called by an algorithm iterates so it doesn’t have much side effects.
Even though my problem is solved but I’ll try pause the renderer and see the effects and report it here if I got something. Maybe it’ll be useful for someone.
If you remove things from the scene graph then they aren’t rendered anymore.
…but it sounds like maybe you are bypassing most of JME’s normal rendering, so yeah, all bets are off and you may just go to OpenGL directly at that point.
: