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 
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.
I’m not entirely certain that this method got pushed in JME 3.0 - but it appears to be on the 3.0 branch, so maybe it is.
I remember I mentioned a few times that the threads for the LOD control were not being released, and the method .setExecutor allows you to use a threadpool and give the LOD control that instead, which has the effect of it not creating it’s own thread - and thus alleviating the problem.
You can check if this is your problem by viewing the thread panel in the netbeans SDK when you run the project in debug mode. There should be an increasing amount of threads as the terrains load and unload.
Sorry, I have a time difference in Asia, last night was trapped fell asleep.Lod can’t be recycled free memory?
Now it is 9 o 'clock in the morning
Is your problem the same as this maybee?
Just with a larger memory penalty as your terrain contains way more stuff?
Well, that I can only put the terrain to do a little bit small