A programming language is a tool. When choosing the right tool for the job, you want to have good information about it. I’ve worked with both C and Java, and have dealt with a lot of misconceptions about both. I’m going to try and generate some data to use in helping guide discussions about the different languages. Consider this, then as the next instalment of my comparison of programming languages that I started in my IPv6 days.

This article will start with the simplest of comparisons: what is the overhead of starting a process in C and Java. Here’s my setup:

I am currently running Fedora 11.

My gcc version is 4.4.1 20090725 .

My version of Java is 1.6.0_0 from  OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)

Here is my C Code:

int main(){
while(1){};
return 0;
}

It was compiled with:

gcc noop.c -o noop

Here is my Java Code

public class NoOp{

public static void main(String[] args){
while(true){

}
}
}

To compile Java that Java code I ran

javac NoOp.java

I then ran both:

./noop &

java NoOp &

Looking at the basics:

diff /proc/12067/status /proc/12069/status
1,4c1,4
< Name:    noop
< State:    R (running)
< Tgid:    12067
< Pid:    12067
—
> Name:    java
> State:    S (sleeping)
> Tgid:    12069
> Pid:    12069
12,13c12,13
< VmPeak:        3884 kB
< VmSize:        3756 kB
—
> VmPeak:     2559076 kB
> VmSize:     2493592 kB
15,17c15,17
< VmHWM:         308 kB
< VmRSS:         308 kB
< VmData:          40 kB
—
> VmHWM:       12304 kB
> VmRSS:       12304 kB
> VmData:     2451848 kB
19,22c19,22
< VmExe:           4 kB
< VmLib:        1548 kB
< VmPTE:          32 kB
< Threads:    1
—
> VmExe:          32 kB
> VmLib:       10632 kB
> VmPTE:         228 kB
> Threads:    12
28c28
< SigCgt:    0000000000000000
—
> SigCgt:    0000000181005ccf
37,38c37,38
< voluntary_ctxt_switches:    1
< nonvoluntary_ctxt_switches:    506847
—
> voluntary_ctxt_switches:    2
> nonvoluntary_ctxt_switches:    2

There are two things that jump out.  First, memory usage for both processes seems incredibly high.  Fora no-op C program to require, at any point in its lifespan, 3884 kB seems quite high.  The Java one, at a massive 2559076 kB borders on the absurd.  Java does have the excuse that the Application Java has certain parameters that are set for minimum and maximum memory usage, so it is possible that a good chunk of that memory was allocated by a system policy.

Another thing that jumps out is the context switches.  Something is forcing the C program to switch roughly 50k times.  The Java program has no such switching.

For the number of files pulled we have, for Java

cat /proc/12069/maps | awk ‘{print $6}’ | sort -u

/lib64/ld-2.10.1.so
/lib64/libc-2.10.1.so
/lib64/libdl-2.10.1.so
/lib64/libm-2.10.1.so
/lib64/libnsl-2.10.1.so
/lib64/libnss_files-2.10.1.so
/lib64/libpthread-2.10.1.so
/lib64/librt-2.10.1.so
/lib64/libz.so.1.2.3
/tmp/hsperfdata_ayoung/12069
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/bin/java
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/jli/libjli.so
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libjava.so
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libverify.so
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libzip.so
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/native_threads/libhpi.so
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/ext/gnome-java-bridge.jar
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/ext/pulse-java.jar
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/rt.jar

Whereas the C program has

cat /proc/12067/maps | awk ‘{print $6}’ | sort -u

/home/ayoung/devel/noop/noop
/lib64/ld-2.10.1.so
/lib64/libc-2.10.1.so

In both cases I removed some garbage from the input, but left the list of files.

OK, some one thing worth noticing is that Java holds on to the C libraries for dynamic library loading and for threading.  Perhaps a better comparison would include those, too.