You can ask java to run the garbage collector with System.gc() but it will delete only the objects that haven’t any reference inside any other active object.
This mean that if you are storing the terrain data inside an HashMap for example, you have to delete the hashmap before.
With this code, if you don’t store node anywhere, you don’t need to do anything else.
The memory will be released the next time the garbage collector will be run.
If you need to run it immediately, you can use System.gc() as I said in the previous reply.
if you still hold this node i.e. a member variable then you have to set to null beside detach.Another story is that if you tell your garbage collector to collect memory it is not guaranteed that it realy will take place immediatly. And it will maybe just do it partial.
Memory management is quite complex, and is probably the reason you question the allocation. It is more the behavior of java than jmonkey itself, but this is a basic run-down of how memory is allocated:
Used Memory: Memory currently and actively in use.
Modified: Memory who’s contents must be written to disk before it can be over-written.
Standby: Memory that contains cached data and code that is not actively in use.
Free: Memory that is not currently in use and will be re-purposed first.
I seriously doubt you will be able to reduce the footprint back to how it started as a result of how the memory is managed. The real question is as @Pesegato said. What happens when you near your memory limit? If you run out of memory - you have a problem that you need to address. If you do not, other than being a little more tidy - there’s little else you can - or should - do.
50 terrainquads at a size of 1024 is way too many. 3 or 4 in front of you would way exceed the camera frustrum. 7 in all directions (7x7 = 49) is way too many. Also, have you added a LOD control to your terrain?
Hmm. hang on. If I recall, adding a LOD control to terrain added an extra thread which will not be removed until you call some method. let me investigate…
and as norman said heap only goes up never down but it will slow down going up and hopefull do not increase any more at some time. heap fragmentation will also be a cause why heap increase. it is highly complex and I suppose you need some VM tools to investigate that.
heap increase when ever the process request more memory from kernel but it never gives that back but reuse it.