I am hunting memory leaks for a while in my project and I cannot manage to solve one particular memory issue.
It seems that collideWith keeps objects in memory. At first I used Mesh.clearCollisionData() for all the results which helped a lot, but still there are objects that remain in memory.
This is data that’s calculated once per mesh to provide optimal performance for colliding with the mesh. Clearing it means that collideWith() must recreated it every time… and then you might as well just not use collideWith()… then it will never be an issue.
@pspeed, not clearing it generates an OutOfMemoryError exception much much more sooner than clearing it.
I use collideWith for determining the distance to the terrain which is procedural generated (not with jme3 terrain).
If the collision data is what’s making you run out of memory then you may have other problems. How high have you set the max heap memory?
Anyway, if your data is procedural then you can probably write a more efficient collision detection yourself… especially if all you want to know is height at a point. That’s probably trivial where are collideWith() has to do a lot of work to answer that same question.
…I mean, your terrain algorithm had to know height at a point already as some point. Just use that.
That looks like a healthy JVM. Since max is set to 2G you probably won’t se a full GC for 20-30 more minutes. The interesting thing is how long will the GC-pause will be when it eventually happen and how much memory can it reclaim.
I don’t know the specifics behind your project, but I feel like you could probably get away with a significantly lower max heap size, which will result in more frequent, yet shorter running garbage collections.
Could your out of memory problems be a result of direct memory usage? I don’t think this is monitored by the profiler. If you’re using Java7 or earlier then, correct me if I’m wrong, the default maximum allocation for direct memory is 64MB. If you’re on Java8 then there’s no default limit for direct memory allocation, it starts at 64MB and scales as necessary, but, obviously, you can’t allocate more than the system has available to it.
So, for instance, say you have 4GB of system memory, 2GB of that are reserved for the heap and say 1.5GB of that is used by the OS and other running applications, that only leaves 512MB for direct memory allocation.