Negative Heap size in Nokia 7210i simulator

[vanvu]

Hi,
I try to trace the heap size by the following test code and receive the value of heap after getResourceAsStream("Q.txt") is just 1776 KB from the initial value 201644 and finally is (-1616)!!!!. However, the application after that still run! What the hell is that! Where is the shadow heap Nokia provide for new created code afte that? In addition, when I open "S.txt" file having size 1,4 KB, the heap remaining after that is 4224 KB even bigger than 1776 KB though "Q.txt"'s size is just 800 B.
Could any body explain this odd behaviour and more over,I notice that a bundle of "op" techs such as .gc(), set null have no effect. I've tried them.
God savings,
// Try code
package Test;
import java.io.*;
import java.lang.*;
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;

public class ReadFile extends MIDlet {
public void startApp() {
InputStream is ;
StringBuffer str=new StringBuffer(100);
String add="";
String filename;
String displayText;
char ch;
byte b[];
int i=0;
Class c;
Runtime runtime = Runtime.getRuntime();
long before, after1,after2,after3;
System.gc();
before = runtime.freeMemory();
System.out.println("Free initial memory is "+Long.toString(before));
//Object newObject = new String();
try {
c = this.getClass();
filename="Q.txt";
is= c.getResourceAsStream(filename);
after1 = runtime.freeMemory();
long size = before - after1;
System.out.println("Free memory is "+Long.toString(size));
b = new byte[1];
while ( is.read(b) != -1 ) {
add=new String(b);
str.append(add);
add=null;
runtime.gc();
};
is.close();
is=null;
filename=null;
b=null;
runtime.gc();
after2 = runtime.freeMemory();
size = after1 - after2;
System.out.println("Free memory after close resource stream is "+Long.toString(size));

Displayable current = Display.getDisplay(this).getCurrent();
runtime.totalMemory();
if(current == null)
{
ch='b';
Short sh=new Short ((short)ch);
displayText=sh.toString();
HelloScreen helloScreen = new HelloScreen(this,displayText);
Display.getDisplay(this).setCurrent(helloScreen);
}

//System.out.println(str);


}
catch (IOException e) {
e.printStackTrace();
}
}

public void destroyApp(boolean b) {}

public void pauseApp() {}
void exitRequested()
{
destroyApp(false);
notifyDestroyed();
}



}
////
class HelloScreen
extends TextBox
implements CommandListener
{
private final ReadFile midlet;
private final Command exitCommand;


HelloScreen(ReadFile midlet, String string)
{
super("HelloWorldMIDlet", string, 256, 0);
this.midlet = midlet;

exitCommand = new Command("Exit", Command.EXIT, 1);
addCommand(exitCommand);
setCommandListener(this);

}


public void commandAction(Command c, Displayable d)
{
if (c == exitCommand)
{
midlet.exitRequested();
}
}
}

[vanvu]

Sorry for my bad arithmetic. The cause of neg value is the bug in code. It's should be.
size = after2 - after1;
Otherwise, the neg value is very very natural.
But the mystery about the difference between heap size remainning after open "Q.txt" file vs"S.txt" file still there. I 've known that getResourceAsStream() eat mem a double size of file but why open smaller file costs more than big file. Is it affected by Size on Disk ?

[vanvu]

Sorry again for my bug. Openning file shouldn't take too much byte. The bug lies in the msg:
System.out.println("Free memory is "+Long.toString(size));
It's should be
System.out.println("Eaten memory is "+Long.toString(size));
So 1776 KB is the price paid to open 800 B as well as 4224 is for 1,4 KB, roughly.
Anyway, I would be very grateful to hear the op tech to open file.
Recently, I've found a book talking about it in JVM though it is written before the creation of J2ME. Quite excellent.!
Please visit:
http://java.sun.com/docs/books/performance/1st_edition
I hope that I will not be fired from this forum for my clumpsy.