Posts Tagged ‘client’

Using WeakReference to confirm/find memory leaks in Java

Friday, September 4th, 2009

I recently had a memory leak in my Trekwar game, and to find it (or at least confirm it’s there) I used the WeakReference object in Java..

This is how I proceeded in locating the memory leak, this method could easily be adapted to other programs.

Trekwar is turn based, so each turn the client downloads a Galaxy object from the server. There are many references to this objects inside action listeners, threads, etc..

WeakReference
To make a long story short, a weak reference is like a normal reference, except it will not prevent the object it points to from being garbage collected.

This means that is you  have a normal and a weak reference to object A, the weak reference will be null if you remove the “hard” reference.

1) In the client main executable (the class that holds the method that updates the map from the server). Import, declare and make a list of weak references

import java.lang.ref.WeakReference;
private ArrayList<WeakReference<Galaxy>> weakRefs;
 
weakRefs = new ArrayList<WeakReference<Galaxy>>();

2) Find the place in your program where a new object is being added, in my place this is the localGalaxy object. Create a weak reference to this object, and list all your weak references.

localGalaxy = (Galaxy) objStream.readObject();
weakRefs.add(new WeakReference(localGalaxy));
for(int i = 0; i < weakRefs.size(); i++) {
System.out.print("ref # " + i + " = ");
try {
Galaxy testG = (Galaxy)weakRefs.get(i).get();
System.out.println(testG + ", tick = " + testG.currentTick);
}
catch(NullPointerException npe) {
System.out.println("null");
}
}

And you’re done!

Now when you run the program, you should see something like this each time the method is called

ref # 0 = org.aakretech.trekwar2.common.Galaxy@11ed166, tick = 37
ref # 1 = org.aakretech.trekwar2.common.Galaxy@9801f4, tick = 37
ref # 2 = org.aakretech.trekwar2.common.Galaxy@1c5d81c, tick = 38
ref # 3 = org.aakretech.trekwar2.common.Galaxy@101f8f4, tick = 39
ref # 4 = org.aakretech.trekwar2.common.Galaxy@1ed1e7e, tick = 40
ref # 5 = org.aakretech.trekwar2.common.Galaxy@e0a7ea, tick = 41

Unless you want to wait until your GC decides it’s time to go, use a tool like VisualVM to force the Garbage Collector to run.

After the GC has run, the output should look like this:

ref # 0 = null
ref # 1 = null
ref # 2 = null
ref # 3 = null
ref # 4 = null
ref # 5 = null
ref # 6 = org.aakretech.trekwar2.common.Galaxy@2b3c91, tick = 42

Now, this means that the object IS being garbage collected, and there is no memory leak.. If you run this and the object you are monitoring (in this example the localGalaxy object) is not GC’ed because of stray references, you can tell because none of the references will point to null.

Trekwar GUI updates

Tuesday, February 3rd, 2009

Recently much of my spare time programming has gone to giving the Trekwar client a graphical overhaul.

Now I’ve managed to get most of what I broke, working again (Research and Starsystem Control), and I’ve added a glasspane that shows up and prevents the clicking of buttons (and thus creating a weird state of the client) while each tick is being processed by the server.

trekwar_feb09_01
Currently the test galaxy is 100×100 tiles and takes about 0.5 seconds to load to client

trekwar_feb09_02

Unlike the previous version of the game, it is now possible to have many windows active on top of the actual game map.
The system box (far left of the screen) has been changed to display more information, and next up is a complete redesign of the fleet box.

But before making the new fleet box and fleet management system, I’ll have to do some major rewrite of the internal ship system and logic, to support user created ship classes.

I’m looking forward to 8-10 hours of pure java and logic.. There is only so much Swing a man can take :)

Goddamn memory leak

Wednesday, September 3rd, 2008

Still havent been able to localize that damn memory leak in the Trekwar client. At least the server  has no leaks :) and can run for days only using around 15-20 MB of memory (galaxy with 10’000 sectors):

The client however will crash after about 10 ticks if the galaxy is really big. Have stared at the code for hours, with no result. I’m going to have to start some methodical and very tedious debugging to get this thing fixed :(

Research done

Wednesday, January 30th, 2008

Today I completely finished the research system of my Star Trek game Trekwar.

Well, I still have to crawl trough memory alpha to get images for all the 65 technologies in the game. but all the code and the GUI is complete:
Trekwar Research view

Next I will make the client download and display the new map / research view each time the server starts a new turn.

After that I will be working on the order system, and doing either the build order system (creating new buildings on planets), or the fleet order system (moving starships, giving attack/colonize orders, etc..). Still LOTS to do, and it feels good to have Research out of the way.