Removed…
hi,
VisualVM helps in such situations. It has a Visual GC plugin (available via Tools->Plugins) which visualizes heap distribution. Heapdumps can also help to see what is going on in the heap.
As a initial estimation you should give the VM at least 30% more heap (xmx) as the VM would require right after a full garbage collection.
Removed…
No idea why it needs so much memory, you should profile it using the memory profiler in NetBeans or Ecliopse.
If your not using either of these IDEs (and your IDE doesn’t allow you to do this) then use the JVisualVM app located in the JDK folder on your PC (on my PC it’s at: C:\Program Files\Java\jdk1.6.0_14\bin\jvisualvm.exe). Run it, then run your game, then switch to JVisualVM, on the left your game should be listed, select it, select the ‘Profiler’ tab, then click ‘Memory’.
It should start displaying results straight away, but I’d advise pressing stop after a while. It will list the amount of bytes that objects take up and how many objects there are. One thing to bear in mind is that things like images and sound take up very little space. It’s the byte arrays inside that take up the memory.
You probably are holding a static reference in your gameclass. So when nulling game, you won’t automatically release the resources you have loaded, because they are somehow linked with the static object. Since all static references are hold by the class itself and not the instance (you create with new …), the resources can’t be freed.
Either that or you are handing over your resources to some system (like swing), that is doing something like the above. I had much trouble with memory leaks when using buttons in swing…
Why not add a reset method to the gameclass instead of recreating it? I implement this by having each entity have a re spawn method that’s called when the game resets. It basically heals the entity and puts them back at their starting location, cancel spells casting, etc.
Swing will screw you over in terms of image memory, as will Java2D. A lot of the time you just can’t do anything about it other than looking for other options to represent everything. :-\
I’ll use this thread because I have a similar question. For example when I think about a game like worms, that allows pixel based manipulation of the level and seems to be based on an image. When creating a BufferedImage big enough to span a few screens, you quickly have a big file. For example 3000 x 2000 pixels, which is about 3 screens wide and 2 screens high, using the default 4 byte per pixel RGBA, takes 22 MB.
I am wondering, if it is possible to store images in a compressed format, like jpeg, and only decode the visible part of it, so that the in memory impact of big images is smaller like a few MB.
-JAW
Nothing to do other than tile a bunch of images, unfortunately. 3000 x 2000 is pretty big, though. Typically you’d just have a small one then blow it up to fill the screen. That’s why the resolution in Worms games is always so low.
Jaw, I’d advise building some sort of custom level format to state how the level should be painted and if it’s painted or not. Perhaps splitting the level up into a grid say 300x200, and each grid section either says it’s filled (i.e. solid ground), empty or it contains a 10x10 array containing the level information for each pixel in that grid section.
In theory it should be far cheaper to represent empty space and solid ground, which hopefully will make up a good percentage of most levels. The graphics could then just be smaller images.
On the other hand 22mb these days isn’t that much memory.
Well I thought about maybe loading the raw bytes of a jpeg and decode it on the fly and use only the required portion. But the idea of splitting might be even better, splitting the image into several images of a few hundred pixels wide. I’d just need to reencode unused image parts into jpeg or compressed binary data.
But actually, you are right there too, nowadays Gigabytes of Ram are typical. I should just go ahead an do something, and measure and optimize afterwards. One should not try to optimize beforehand, for you never know, if the optimization is needed at all.
-JAW