Well, everything’s working nicely in my mini sokoban game. I have made it so that every time you win, u go to the next level.
I’d just like to ask something. It’s weird, but every time i get to the next stage, another 300-400kb of ram is added to the 65Mb needed to run the game. I can put some code and explain what i do, but only if this isn’t normal (it doesn’t sound normal)…
Everytime i use a stage, i put
LevelMap = null; // these levelMaps are simply a multidimensional array of integers or booleans, for use with the game logic
LevelMapFinale = null;
LevelMapNodes = null;
rootNode.detachAllChildren();
CreateFloor(); // this just creates a quad…If i don’t put it here, there’s no floor
CreateSky(); // same for skybox
CreateSphere(); // same for sphere
After that
LevelMap = new int[LevelX][LevelZ];
LevelMapFinale = new boolean[LevelX][LevelZ];
LevelMapNodes = new Node[LevelX][LevelZ];
CreateCubeMap();
The last thingy is what creates the meshes…Apart from the cubes themselves, the only assignment is this
LevelMapNodes[j] = CreateMoveCube(new Vector3f(i * 2, 1, j * 2).add(-LevelX, 0, -LevelZ));
which fills the mapNodes…
Inside the cubes that get created is code just like this
Box B = new Box(V, 1, 1, 1);
Spatial Cube = new Geometry(“Cube”, B);
Material myMateria = new Material(assetManager, “Common/MatDefs/Light/Lighting.j3md”);
myMateria.setTexture(“DiffuseMap”, assetManager.loadTexture(“Textures/Box.jpg”));
myMateria.setBoolean(“m_UseMaterialColors”, false);
myMateria.setColor(“m_Ambient”, ColorRGBA.White);
myMateria.setColor(“m_Diffuse”, ColorRGBA.White);
myMateria.setColor(“m_Specular”, ColorRGBA.White);
myMateria.setFloat(“m_Shininess”, 1);
Cube.setMaterial(myMateria);
rootNode.attachChild(Cube);
Any ideas??? should i be worried??? i can just ignore this and move on, but i really wanna know what’s happening :S
What happens if you do a System.gc() after?
I would assume, that since you don’t run out of memory, the jvm simply does not feel a need to garbagecollect.
That was nice, and did force the garbage collector. Still, i get from 2 to 80(rarely) kb increases without any of it being reduced every time i level up. I put the System.gc() after detaching the nodes and loading the sky and floor… thanks though, that really helped deal with the bulk of the problem
From my (meager) understanding of java memory management I believe it works by just cleaning when it needs to. I think it determines this by how much memory the jvm is allocated when the application runs. So for instance when you run a jar from command line you can tell it the maximum amount of memory to use (by default it’s in the hundreds of Megabytes I believe). So ya. I wouldn’t really worry about Java gobbling up memory or forcing it to do garbage collection in your code personally.
thecyberbob said:
I wouldn't really worry about Java gobbling up memory or forcing it to do garbage collection in your code personally.
Technically speaking, you can never force a garbage collection.. Calling System.gc() rather suggests to the JVM that it run a garbage collection. You want to be very conservative with your use of the command, as it is by nature unpredictable and blocks until completion. The general advice is look to application design before trying to run garbage collection. That said, sometimes it works, as it seems to above :)
And sometimes if you really want it to clean you have to ask it a few times.
Note also that any direct memory used (like the type that JME uses for meshes and textures) will not trigger a GC at all. And the default Java heap size is pretty big… this means that direct memory can hang around for quite a while.
pspeed said:Note also that any direct memory used (like the type that JME uses for meshes and textures) will not trigger a GC at all. And the default Java heap size is pretty big... this means that direct memory can hang around for quite a while.
Shouldn't the direct access buffer be finalized on GC?
A GC will free direct memory… but direct memory won’t trigger a GC. So if you have a huge heap and never see the end of it… your direct memory will hang around forever.
In Mythruna, I got better performance by increasing direct memory and cutting my max heap size in half. Shrinking heap made me stop getting out of memory errors. It’s only counter-intuitive until you think about it. 
u did mythruna? omg
dimitristrigkakis said:
u did mythruna? omg
That's me! :) I had no idea I was becoming famous. :)
pspeed said:
A GC will free direct memory... but direct memory won't trigger a GC. So if you have a huge heap and never see the end of it... your direct memory will hang around forever.
In Mythruna, I got better performance by increasing direct memory and cutting my max heap size in half. Shrinking heap made me stop getting out of memory errors. It's only counter-intuitive until you think about it. :)
Interesting, you learn something new every day :)
We should throw a note about this in the wiki.. its definitely not part of normal GC knowledge