memory management

[edalquist]

I have two little programs that do the same thing. One leaks memory very quickly the other doesn't at all. Could someone point out the problem with the leaky version?

Good version:

Code: Select all

import lejos.nxt.LCD;

public class MemTest {
    private static String M = "M:";

    public static void main(String[] args) {
        while (true) {
            LCD.clear();
            LCD.drawString(M, 0, 7);
            LCD.drawInt((int)Runtime.getRuntime().freeMemory(), 5, 3, 7);
            LCD.refresh();
           
            try {
                Thread.sleep(1);
            }
            catch (InterruptedException ie) {
                //oops
            }
        }
    }
}


The leaky version:

Code: Select all

public class MemTest {
    private static Display display = new Display();

    public static void main(String[] args) {
        while (true) {
           display.updateDisplay();

            try {
                Thread.sleep(1);
            }
            catch (InterruptedException ie) {
                //oops
            }
        }
    }
}



import lejos.nxt.LCD;

public class Display {
    private static final String M = "M:";
   
    public void updateDisplay() {
        LCD.clear();
       
        LCD.drawString(M, 0, 7);
        LCD.drawInt((int)Runtime.getRuntime().freeMemory(), 5, 3, 7);
       
        LCD.refresh();
    }
}


Everything is declared static, exact same operations on the lejos APIs, can't see where I'm leaking from.

[edalquist]

So looking at my post again I just noticed something innocuous . The leaky version declares the static field as final where as the good version doesn't. I just did a few more tests and it appears using the 'final' keyword on any variable (field, parameter, local) causes a leak every time the variable is referenced (like creating a new instance each time).

So the moral of the story is .... don't use the final keyword.

[bbagnall]

Thanks for finding that. There must be something in the drawString() method that requires a non-final String. We'll add that to our list.

[edalquist]

No problem, is there an appropriate way to report bugs or do the forums work?

PS ... great software, I'm having a lot of fun being able to hack in Java on the NXT. If I could remember any of my C++ from college I'd offer to help with the OSX port but I'm not sure how much help I could be there.

[bbagnall]

There's no real C++ coding required for the OSX port. Just need to be able to build it, which many have already done. We can't seem to get any Mac users to volunteer their binaries (preferably the Universal binaries).

[edalquist]

Hrm, I may see if I can find some time in a week or two to look at setting up an XCode project to do the build and contribute that back. I could probably handle doing OS X universal builds for the project.