Questions about the release and recycling memory?

Hello everyone, I have a memory release problems, has been bothering me for a long time haven’t find a solution.
My side load a lot of j3o terrain files, memory is more than 1 GM

Then when I want to switch scene using node.detachAllChildren(); Unable to delete the memory resources

Excuse me what method can release the memory?


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.

I use

  Node  node=(Node) assetManager.loadModel("terrain/terrain_01.j3o");
    rootNode.attachChild(node);

uninstall
rootNode.detachChild(node);

This way how to release the memory resources

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.

Before loading

After loading

System.gc();

Memory can be back to the original state

Yeah, the assetManager keeps a cache of every model you load, try in this way:
Load:

ModelKey key=new ModelKey("terrain/terrain_01.j3o");
Node node=(Node) assetManager.loadModel(key);
rootNode.attachChild(node);

Unload:

rootNode.detachChild(node);
assetManager.deleteFromCache(key);

I tried just now, there is no effect

rootNode.detachChild(node);
            ((DesktopAssetManager) assetManager).deleteFromCache(key);

Do you have any crashes or issues?

If not, just let hotspot do the job its supposed to.

I’m going to test your method, memory has not been released

Well… do you have a memory leak somewhere? From what I see:

start game: 45Mb
load: 189Mb
gc(): 147Mb

It might not be possible to go back to 45Mb; and it’s probably not what you want: models get cached because you may need them later on etc.

The REAL problem is when you load another level and the memory allocation keeps growing without limit.

Please confirm that the more level you load/unload, the more memory gets allocated.

Also: nice screenshot :wink:

What I do is the game I’m under a lot of scenes of Chinese ancient costume, each load scratchable latex map, I worry about when I can’t walk 10 minutes to 2 gb of memory is terrain file is depleted

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.

Whether can file all of the memory ?

The only solution?

   rootNode.detachChild(node);
    node =null;
    System.gc();

Whether the program can be reset to zero memory

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.

You are looking at the java process memory in your task manager, that memory will never go down, only up, even when your application has a completely empty heap.

If I have 50 terrain file ,The size of 1024,I go straight ahead, and constantly loading, and unloading, will finally out of memory

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.