My work on the s390 port of CACAO was finished around the beginning of summer 2007. Our criteria for the port to be finished were:

• Passing all benchmarks of the dacapo benchmark suite.
• Passing the mauve test suite. This turned out to be useful as some tests have still located bugs.

As the work was part of an internship, i had to document it. This took some time in the summer 2007. The documentation was finished around the beginning of fall 2007 and checked as part of the CACAO Handbook into the mercurial repository in docs/s390.tex.

The internship finished, time has come to start working on a master’s thesis. I’ve got 2 subjects to choose from: implement escape analysis for the optimizing compiler or rework the framework of the optimizing compiler. After taking one month to have a look at both subjects, I have chosen to work on escape analysis.

After having followed twisti’s build instructions on how to build cacao with OpenJDK as runtime, I’ve got an OpenJDK based JRE with Cacao as VM in JIT mode on s390. Here’s the usual first real life app run:

$ ~/j2re-image/bin$ ./java -cp /usr/share/java/jython-2.1.jar org.python.util.jython
LOG: [0x77e626b0] JVM_GetStackAccessControlContext: IMPLEMENT ME!
LOG: [0x77e626b0] JVM_DesiredAssertionStatus: cls=0x475d20, IMPLEMENT ME!
LOG: [0x77e626b0] JVM_DesiredAssertionStatus: cls=0x474d20, IMPLEMENT ME!
LOG: [0x77e626b0] JVM_DesiredAssertionStatus: cls=0x475a80, IMPLEMENT ME!
...
LOG: [0x77e626b0] JVM_GetSystemPackage: IMPLEMENT ME!
Jython 2.1 on java1.7.0-fastdebug (JIT: null)
...
>>> import java.lang.System as s
LOG: [0x77e626b0] JVM_GetProtectionDomain: cls=0x5fed20
LOG: [0x77e626b0] JVM_ResolveClass: IMPLEMENT ME!
>>> [s.getProperty(p) for p in
    ['java.vm.name', 'java.runtime.name', 'os.arch', 'java.vm.info', 'java.version']]
LOG: [0x77e626b0] JVM_GetProtectionDomain: cls=0x5fed20
LOG: [0x77e626b0] JVM_ResolveClass: IMPLEMENT ME!
['CACAO', 'OpenJDK Runtime Environment', 's390', 'JIT mode', '1.7.0-fastdebug']

I’ve run the dacapo benchmark against cacao/s390 and compared the results with IBM’s java 1.4 and 5.0 for s390. A prerelease of Java 6.0 is also available from IBM, but benchmarking is prohibited.

The benchmarks were run on a virtual machine with 256 MB RAM and a lot of swap on the Community Development System for Linux.

Every benchmark was run 5 times with default data size, the table below shows the worst and best run on each VM.

The results are available as histogram too.

Finally, eclipse is running on cacao/s390:

I’ll try to briefly explain what cacao does using the well known hello world program:

class xhello {
    public static void main(String[] args) {
        System.out.println("hello");
    }
}    

The main method is compiled the first time it is called (just-in-time). Cacao first transforms the corresponding bytecode into an intermediate representation very similar to java bytecode. This intermediate representation is processed in passes. One of the passes allocates stack slots to registers or memory locations:

The static member out of java.lang.System is placed on the top of
stack (mapped to r2).
        | 0:  GETSTATIC
              <field> java.lang.System.out Ljava/io/PrintStream;
              PUBLIC STATIC FINAL
              => Aa4( r2)
The constant "hello" is placed on the top of stack (mapped to r3).
        | 1:  ACONST
              0x0086b7f8 "hello"
              => Aa5( r3)
The virtual method java.io.PrintStream.println is called.
The object reference and the sole argument are poped from the stack
(mapped to r2 and r3).
        | 2:  INVOKEVIRTUAL
              Aa4( r2) Aa5( r3)
              java.io.PrintStream.println(Ljava/lang/String;)V
              PUBLIC
Return from function.
        | 3:  RETURN

In the final pass, machine code generation, the intermediate representation is transformed into machine executable code:

Prologue
        | ahi      %r13,-4092
Allocate stack frame
        | ahi      %r15,-16
Store return address
        | st       %r14,12(%r15)
Get java.lang.System.out into argument register #1
        | l        %r1,4052(%r13)
        | l        %r2,0(%r1)
Load "hello" into argument register #2
        | l        %r3,4048(%r13)
Load virtual function table pointer of java.lang.System.out
        | l        %r12,0(%r2)
Load method address from virtual function table
        | l        %r13,192(%r12)
Call method
        | basr     %r14,%r13
Restore procedure vector (literal pool pointer in s390 terminology)
        | basr     %r13,%r0
        | ahi      %r13,-4128
Load return address
        | l        %r14,12(%r15)
Remove stack frame
        | ahi      %r15,16
Return
        | br       %r14
NOP
        | bc       0,0

One interesting aspect of cacao is the way it checks for null pointers. In java, operations on objects have to check if the object reference is null. If so the runtime system has to throw a NullPointerException. A naive implementation of this requirement would do a null pointer check before each such operation. Cacao translates a GETFIELD operation into a simple load:

Load the member field mem of the instance (r11) of klass and place it on
top of stack (mapped to r3).
        | 4:  GETFIELD        La0(r11)  klass.mem I => Ai7( r3)

No null pointer check here
        | 0x773a2314:   58 30 b0 0c                      l    %r3,12(%r11)

If the object reference in %r11 is null a SIGSEGV is raised. The installed signal handler examines the machine code and registers that caused the signal. If they correspond to the usage of a null pointer, a NullPointerException is raised.

Some screenshots of a simple swing application displaying system properties and the foxhunt game running on the s390 cacao port:

The first real world java application I made the s390 cacao port run was my favorite one, jython:

$ ~/cacao-dev/inst-s390/bin/cacao -jar jython.jar
Jython 2.2a1 on java1.5.0 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> map (lambda p: java.lang.System.getProperty(p),
... ["os.arch", "os.name", "os.version"])
['s390', 'Linux', '2.6.17-2-s390']