Memory residence

[Andrew Haley]

shudo@computer.org writes:
 > Generally speaking, AOT compilers like GCJ are known to be
 > advantageous to JVMs which interpret and/or compile Java bytecode.
 > I observed memory occupation of Java programs with GCJ 4.0, gij and
 > JDK 5.0 on a Linux box.
 > 
 > 
 > The first Java program is very simple one which just pauses for 60 sec:
 > 
 >   public class Pause {
 >     public static void main(String[] args) {
 >       try { Thread.sleep(60000); } catch (InterruptedException e) {}
 >     }
 >   }
 > 
 > Memory occupation of the program (and a runtime) shown by 'ps' command
 > is as follows:
 > 
 >   [gcj -O2]
 > 
 >   USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
 >   shudo    22322  5.0  2.4  34512 12560 pts/6    Sl+  05:07   0:00 ./Pause
 > 
 >   [gij]
 > 
 >   USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
 >   shudo    22329  4.0  2.0  37580 10640 pts/6    Sl+  05:07   0:00 gij Pause
 > 
 >   [JDK 1.5.0_03]
 > 
 >   USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
 >   shudo    22246  1.8  1.9 262316  9848 pts/6    Sl+  05:05   0:00 java Pause
 > JDK 1.5 showed the least number in RSS.
 > 
 > 
 > Another Java program is Eclipse, an IDE. The version runs with JDK 5.0
 > is 3.1M7 and one with GCJ is 3.1M6 I found in the current development
 > version of Fedora Core 4. Initial heap size was set as 40 MB in all cases.
 > 
 >   [GCJ]
 > 
 >   USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
 >   shudo    22108 85.8 27.0 298872 139488 pts/5   Sl+  05:00   0:19 ...
 > 
 >   [JDK 1.5.0_03]
 > 
 >   USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
 >   shudo    21990 23.5 16.3 511188 84068 pts/5    Sl+  04:57   0:08 ...
 > 
 > JDK 1.5 showed less number then GCJ in RSS again.

You've got to be very suspicious of these simple numbers.  gcj, like
gcc, uses the system shared library loader to memory-map all of the
shared libraries that are used.  These appear in both the virtual and
resident set sizes.  However, the shared libraries are shared between
processes, so memory consumption figures for a single process may be
misleading.

Also, measuring RSS is deceptive because if your system had been busy
at the time, the pages belonging to your gcj process would have been
paged out, thus reducing the apparent footprint.  

Also, it may be that the libraries for Eclipse are compiled without
any optimization, and this generates a lot of code.  I'm not sure
about this.

Finally, there's no reason to suspect that ahead-of-time compiled code
will be very much smaller than JIT-compiled code.  For sure, there
isn't the memory overhead of the JIT compiler itself, but I don't
suppose that's very mich when compared with the Eclipse libraries.

 > Today, we cannot claim that GCJ is superior to usual JVMs in memory
 > consumption. Is this correct? Could GCJ be improved?

Probably.  Yes.  It depends on what the system is tuned for.

Andrew.