Hello, this post is a followup to this post, in my quest to eliminate (as much as possible) memory growth. In that post, I eliminated a large portion of the problem, but enough remains that it is still affecting my game. In short, free memory is growing outside of my managed code, which is causing frequent garbage collection sweeps, which cause brief app hangs and choppiness.
Right now the most frequent memory growth Im seeing is in the call to renderManager.render(tpf); in SimpleApplication.java. For clarification, Im simply enclosing that method call with “PrintCheckMem” calls from the linked post above, which simply prints out the current memory and diff, if growth occurred:
Main.printCheckMem(“A”);
renderManager.render(tpf);
Main.printCheckMem(“B”);
The output looks like the following:
B 32334.508 diff 915.4453
A 33249.992 diff 915.4844
A 34165.484 diff 915.4922
B 35080.92 diff 915.4375
B 35996.484 diff 915.5625
B 36911.93 diff 915.4453
B 37827.39 diff 915.46094
A 38742.836 diff 915.4453
A 39658.312 diff 915.47656
B 39749.125 diff 90.8125
B 40664.57 diff 915.4453
A 41176.46 diff 511.89062
As you can see, about half of the growth im seeing are tagged with ‘B’, which means they are from the renderManager.render call. Ive attempted to narrow it down to embedded calls within that method, but there seem to be several different paths that are causing growth, and it will take alot of research to track them all down. Can someone address what would cause this type of memory growth, and if its either a bug or suggest something I might be doing wrong to cause it?
Thanks!
Also, since there are multiple memory issues like this, would you prefer I kept them all in this thread, or make separate ones for each?
Also, this is current to 3/6/2011 nightly build, JME 1.3
It might also be useful to point out that we are not (knowingly) creating new objects or adding anything new to the rootNode, etc. in our update loop. This happens constantly, even with no movement occurring whatsoever
I don’t know if it factors in at all but I’m curious… do you have any post filters setup?
Also curious: how big is your scene, etc.?
Also, what happens when you enable the G1 garbage collector?
What do you mean by post filters? How would I retrieve the size of the scene? I dont believe weve explicitly set a value like that…
Never used G1 before, but I added this to Properties → Run → Arguments:
-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC
I still got the same results. GC and ~100ms frame lag every 8 seconds or so, and this is with a lower frame rate than we would like to use and only 1 model on the screen. The effect gets drastically worse as framerate increases, since the memory builds faster.
Hmmm… that is much worse than I see with mine but I’m also running 1 week old JME. Mythruna thrashes memory and I only see those kind of GC lengths occasionally… but it would be nice to minimize them.
If you don’t know if you are using a post-processing filter then you probably aren’t. These are things like bloom, blur, and so on.
By scene size, I meant how many spatials, etc… when the stats are up, it’s the number of objects.
…or is it just a textured cube? If it is just a textured cube then how does memory behave?
Sorry, I mislead a bit when I said only one model is on the screen. What I meant was there is only one character model. We also have Gui components such as BitMapText, some health bars which are boxes, and a “star field” which is just a bunch of small white boxes.
Adding or removing any of these seem to directly effect the growth speed. When I went down to just rendering the player models, the growth was very slow. Adding in the star field (which is never updated after initialization) greatly sped it up, and adding name labels and health bars did also. I cant seem to assign a pattern to it other than any spatial added to the scene seems to cause more growth.
Also, there are anywhere from 80-120 objects at any time in the guinode stats display with everything turned on (most of which are stars), varying depending on where my character is at the time. Without the starfield its about 45-57 objects
Ok, I’ve seen that there is some book-keeping that render manager does once per frame and that is related to the number of ‘objects’ but your count doesn’t seem overly high. For example, RenderQueue rebuilds its list of Geometries every frame and even though it reuses its lists to try and save memory churn it sorts this lists which forces a copy. It’s sort of unavoidable and these lists are just arrays of object references that are easily GC’ed at any time.
If you change your BitMapText often then this will run through some amount of memory as well. It churns through string buffer memory as well as creating internal representations, etc. every time you call setText(). If you are calling setText() once per frame even if the value isn’t changing then (at least until this issue is fixed) stop doing that. 
Since the star field was a big change, it makes me curious to learn more about how that is constructed… what it’s materials are, etc.
As a point of reference, if I run the latest version of Mythruna and turn off stats (F3) and watch the task manager’s memory consumption, I see it stay pretty steadily at 402 meg. Max is set to over a gig so I know it would grow if it wanted to (and I’ve seen my app take way more than that as I’m pacing around). Sitting still with no stats, I have 499 objects (big meshes) on the screen and no appreciable memory gain.
I will update to the latest code tonight and see if this changes… my current version of JME is about a week old, I think.
Thanks for the heads up on BitMapText. I checked and we are not calling setText except on creation.
We create the individual stars like this then add to rootnode:
Node node = new Node(“StarField”+x);
Box boxshape1 = new Box(starSize, starSize, starSize);
Geometry cube = new Geometry(“My Textured Box”, boxshape1);
Material mat_stl = new Material(Main.getMain().getAssetManager(), “Common/MatDefs/Misc/SolidColor.j3md”);
mat_stl.setColor(“Color”, ColorRGBA.White);
cube.setMaterial(mat_stl);
Another thing I should mention is that the numbers I included in my OP are in KB. So, my used memory is oscillating roughly from 10mb to 60mb every few seconds.
How many stars?
starSize is .3f and there are 1000 of them, but obviously not all on screen at once
Still… that’s a lot of objects to throw at the renderer and may be significant. As an aside, in the long run you will probably be better off if you can use a point mesh with some point sprites.
Thanks, ill look in to that. However the issue is still there even without starfield
Yeah. I’m still updating to latest JME. I do it step by step in case I see something weird so it takes me a bit.
Ok. I’ve updated to the latest and my app still shows no appreciable memory gain over time. I watched it stay at 403 meg for over a minute.
To confirm: you see this memory churn even if you never move the camera from its initial position?
What (if anything) are you doing on simpleUpdate() (or whatever update mechanism you are using, app states, or whatever)?