Salsa Manual

• Installing Salsa
• How to use Salsa
• Compiling the Javac compiler
• Choosing between the GC and the non-GC version

Installing Salsa

To install salsa:

• Retrieve the appropriate salsa.target_platform.tar.gz file.
• Uncompress and untar the file in the installation directory. The tar contains the following directories:

  bin/
  include/
  lib/
  lib/mmwithgc/
  lib/mmwithout/
  doc/
  

• Edit the file "bin/salsa_config.tcsh". Set the JDKLIB variable with the directory where the file "classes.zip" can be found. Set the SALSAHOME variable with the name of the directory where salsa has been installed. Choose between the GC and the non GC version by commenting/uncommenting the appropriate line.
• Execute "source bin/salsa_config.tcsh" each time you start a new session, or modify your .login accordingly.

How to use Salsa

Salsa offers two commands:

• salsa: a Java interpreter;
• salsa2c: a bytecode-to-C compiler.

Salsa

salsa is a Java interpreter. Its syntax can be obtained by executing it with no parameters:

Salsa version alpha2.0 copyright (C) Irisa/Inria 1996
syntax: salsa [-p] class args...
-p : generate profiling information
'class' is a class containing a 'main' method which will be launched.
        Its signature must be  'public static void main(String[])'.
'args' are the arguments given to the 'main' method.

The profiling information is written into the files vm.prof and call.prof.

• The file vm.prof contains an accurate bytecode instruction count. At the end of the file, some global statistics are given.
• The file call.prof contains a list of all dynamic call sites encountered during the execution of the program. For each call site, a list of all the methods called is given. At the end of the file, globals counts are given.

Salsa2c

salsa2c is a Java to C translator. A C source file is generated for each Java class used by the compiled application. The syntax can be obtained by executing salsa2c with no parameters:

 salsa2c version alpha2.0 copyright (C) Irisa/Inria 1996
syntax: salsa2c [-C] [-o object] [-i size] [-B] [-T] [-P] [-g] [-R] [-J]
                [-h] [-d path] command classes...
'command' : one of header,stub,src,code,prog
'classes' : the Java classes to handle
-h : print this help
-B : no bound checks
-T : no type checks
-i size : allow method inlining when bytecode size <= size
-s : assume that no class will be loaded dynamically
-P : print bytecode within each method
-C : Class Hierarchy Analysis
-J : Generate a jump to a common label for index bound exceptions (default for i386)
-R : Generate a dummy return after index bound exceptions (default for the SPARC)
-g : include source file information (name of variables, name of fields)
-d dir : directory of generated C sources (default='./gen')
-o object : name of executable binary (default='a.out')

When you compile a Java program into C, the C source files are written by default within the directory ./gen. A Makefile is also created. To compile the C sources you only need to go in the gen directory and type make.

Behavior of commands:

• prog is used to translate a whole Java program. Only the class containing the main method should be given. It should be given without the ".class" extension.
• code is used to translate only one class. It is provided for debugging purpose only.
• header, stub and src are used to create headers and C sources to implement native Java methods. See the SUN program javah for more details.

Behavior of options:

• -B disables the generation of bound checks in the C code.
• -T disables the generation of type checks in the C code.

The purpose of the two previous options is to estimate the effective cost of checks in an application. It is not recommended to use them since the generated program does not follow Java semantics and the application is less reliable.

• -C performs an analysis on the hierarchy of classes. Its purpose is to tell if there is only one target method associated with a call site. If so, the method call is replaced by a static procedure call.
• -i size enables method inlining when bytecode size is lower or equal to size for methods that have been transformed into procedure calls.
• -s assumes that no class will be loaded dynamically. Stubc procedures that call the interpreter from the compiled code are not generated so as to reduce code size.
• -J generates a jump to a common label for index bound exceptions. This is the default for the i386.
• -R generates a dummy return after index bound exceptions. This is the default for the SPARC.

  -J and -R options are mutually exclusive. We found that puting either a jump or a return gave more control-flow information to gcc especially for array accesses embeded in loops. Caching of intermediate results in registers is more effective and the binary code is more efficient.

• -P prints bytecode within each method.
• -g includes source file information (name of variables, name of fields). It is still buggy and fails when compiling javac.
• -d permits the overriding of the directory where C sources are generated (default='./gen').
• -o specifies the name of the executable binary (default='a.out').

At the current time, salsa relies on some GCC (version 2.7.2) C extensions. However, the code can be post-processed using the Suif optimizer in order to remove transient variables and beautify the code.

Compiling the Javac compiler

Create a gen directory. Then, type the command:

  salsa2c -C -i100 -s -o salsac prog sun.tools.javac.Main
  cd gen; make

On a PC/Pentium 90 Mhz, C code generation takes about 2 mn. C code compilation by Gcc 2.7.2 with the "-O2" option takes about 8 minutes.

Choosing between the GC and the non-GC version

Salsa is provided in two different configurations with and without Garbage Collection. The GC version is based on the Boehm-Demers-Weiser conservative garbage collector. The non GC version is based on the system malloc primitive. Since objects are never deallocated, it leads to an increase of the heap segment and a slow down of the application due to disk swapping.

The choice between the two versions is done by linking the application either with lib/mmwithgc/libmem.so or lib/mmwithout/libmem.so. To switch between versions, you have to change the LD_LIBRARY_PATH and SALSA_LIB_MEM variables. Also, since the libmem.so library is statically linked with the program, the link phase has to be redone. To to so, the application binary must be removed and the make restarted.