how large is your heap?

Performance Tuning
#1

hello,

i recently noticed that the heap of my game increases beyond 64MB so i have to manually increase the heapsize at startup in order to make it run reasonably.
that made me think, is such a large heap common among java games? or am i having a leak somewhere?

so what size is the heap in your game?

#2

You’ve probably got a leak. 2D ‘small’ games usually don’t use more then 20megs. Listeners that you forget to remove are often the trouble, or sometimes it is references in HashMaps that are never removed. Use the Netbeans profiler to figure out when the heap increases.

Keith

#3

thanks.
i am using a lot of textures (JOGL) and it seems, they are causing the problem. but shouldnt texture data be on the VRAM only? it seems they are resident in the HEAP as well. :-/

#4

If you know that’s the reason then it should be OK. I don’t use JOGL but don’t you load your images using ImageIO, which loads them into normal RAM? From there I think they’re put on VRAM, but if you keep a reference to them then there’ll be a copy on normal RAM too.

If you don’t want to use so much of the heap you could load only the images you need per level. Otherwise Web Start lets you set the heap to be bigger than 1.5’s default 64meg.

Keith

#5

You got it spot on CommanderKeith with regards to textures. When textures are loaded into OGL, the data is copied to the server side of OGL meaning you have two copies of the same thing. The most ironic part is that if VRAM is full (or what the driver deams as full), the texture data that is copied could end up in RAM! So your getting bad performance, and double memory concumption…

#6

Then I made a lucky guess :P… I thought as much since Java2D’s BufferedImage & VolatileImages work similarly.

Off-topic: There are similar problems in Java2D - trouble is that images can be punted between RAM & VRAM on windows depending on how often they are read-from (causes a punt from VRAM -> RAM) & written to the screen/VRAM (causes a punt from RAM -> VRAM). You have to set a VM flag to disable this when using the default pipeline unless you want episodes of high performance interspersed with sluggishness when, say, there’s too much anti-aliasing/alpha-blending happening & the VRAMed image is punted to RAM.

Keith

#7

This advice also goes for static geometry in OGL, display lists, VBOs…even GPU skinned models; they all take up VRAM…

So why waste RAM?

#8

thanks guys!

so is there anything i can do about the double storage of image data? since i dont need it in ram anymore once it is uploaed to VRAM, i should be able to remove it, but how?

#9

While it’s correct that sometimes textures and other GL state are stored “twice” in memory, it’s not as simple as that:

  1. No amount of memory usage by the GL subsystem (JOGL or LWJGL or whatever) is counted towards your java heap usage. Only java objects count towards that default 64 meg limit, even direct ByteBuffers don’t count (except for a small header allocated on the java heap). So a lot of textures are only taking up space in your java heap if you keep a redundant reference to the image data around.
  2. Even though you might find it useless to keep a copy of textures in both VRAM and “system” RAM, it is necessary for reasons of memory management - if someone needs the VRAM it’s not always possible or efficient to copy the texture to RAM, delete it in VRAM and free the space. And sometimes, the video card and system shares a part of the system memory, allowing the video card to render directly from the system RAM without double storage.
  • elias
#10

AFAIK all GL textures are stored in system memory, and swapped in and out to the card as needed by the driver.

Cas :slight_smile:

#11

then what could it be that my heap is getting that large?
if i profile it using the netbeans profiler, most data is of type “byte[]”.

#12

Sounds like images to me, left in the Java heap by accident.

Cas :slight_smile:

#13

thanks.
hmmm, probably buffered images. how could they be left int the memory by accident?

#14

Ask the profiler to show you the path from the (Buffered)Images to a (or all) gc roots. That should give you a pretty good idea of what’s happening. (disclaimer: I’ve never used the netbeans profiler myself, but it would surprise me if that functionality is not available)

#15

don’t forget to flush() the BufferedImages

If i don’t do that, I get a OOME pretty quickly (processing dozens of 2500x1500px pictures)