I have this basic program which does nothing but sit there waiting for input:
import java.io.*;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
public class Basic {
public static void main(String[] args) throws Exception{
try{
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
String input;
input=br.readLine();
}catch(IOException io){
io.printStackTrace();
}
}
}
And when I run this:
java -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=15001 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false Basic
I connect via JConsole to see this:
Is that simply because core java bytcode is being compiled at first? How can the codecache be increasing when the process is not doing anything?
And when I have this version (which uses Thread.sleep
):
public class Basic {
public static void main(String[] args) throws Exception{
while(true) {
Thread.sleep(5000);
}
}
}
I get this:
So... why is this happening?
P.S. this is the output of java -version
:
java version "1.6.0_37"
Java(TM) SE Runtime Environment (build 1.6.0_37-b06)
Java HotSpot(TM) Client VM (build 20.12-b01, mixed mode, sharing)
I suspect that it is jconsole
itself that is causing the problem. Or more precisely, the jmxremote stuff that allows jconsole
to see what is going on inside your JVM.
My advice:
Don't worry about it. It looks like it has almost reached a steady state.
If that's not good enough, then leave jconsole
running for a very long time and observe if the memory usage growth stops completely.
If that's not good enough, then you could try to profile it ... though tracking down small storage leaks in the jmxremote code (with or without source code) could be challenging.