JavaCodeCompact for CVM

java [ Java options ] JavaCodeCompact [ options ] filename ...

Description

JavaCodeCompact combines one or more Java class files and produces a target system-dependent C file that contains the given classes in a preloaded format that can be compiled and linked with the Java virtual machine. It also provides a way to ensure that certain, necessary classes are present and fully linked. This expedites the CVM's startup and error handling procedures.

Linking Java Programs

Here is an outline of the conventional mechanism for class loading:

JavaCodeCompact provides an alternate means of program linking and symbol resolution, one that provides a less-flexible model of program building, but which helps reduce the VM's resource consumption.

JavaCodeCompact will:

Note: It is a good idea to increase the maximum heap size by using the -mx Java option. For example, -mx20m increases the maximum heap size to 20MB.

Options

filename
Designates the name of a file to be used as input, the contents of which should be included in the output. File names are not modified by any pathname calculus. File names with a .class suffix are read as single class files. File names with .jar or .zip suffixes are read as Zip files. Class files contained as elements of these files are read and included. Other elements are silently ignored.

-maxSegmentSize num_classes
Specifies the maximum number of classes to be represented in any one output file. Requires use of the -o option to specify output file name. See the section on Output.

-o outfilename
Provides a template for the name of the output files to to be produced. See the section on Output.

-qlossless
Preserves more information about the original program in the output file for use of the debugging using the JVMDI debugger interface. See the section on Opcode Transformations for a description of the "quickening" process, which is modified by the option. This has a small performance impact on the running system.

-c
Cumulative linking. Classes unresolved by the linking of class files explicitly listed as linker arguments are searched for using the -classpath option, and linked as they are found.

-classpath path
Specifies the path JavaCodeCompact uses to look up classes. Directories and Zip files are separated by the delimeter defined by java.io.File.pathSeparatorChar, which is generally a colon. Multiple classpath options are cumulative, and are searched left-to-right. This option is only used in conjunction with the -c cumulative-linking option.

-nativesType native_type classes
Indicates the calling convention to be used for native methods of the listed classes. The CNI native type is for use only by classes intimately involved with the virtual machine implementation. All other classes must use the JNI convention. The option sequence "-nativesType JNI -*" informs JavaCodeCompact of the default type.

-headersDir header_type target_directory
Controls the location of C-language header files generated by JavaCodeCompact. Header files for classes of the indicated header_type are written in the indicated target directory. Existing header files unchanged remain untouched. A header_type is either a native_type, as described with the -nativesType option above, or an extra_header_type, as described below.

-extraHeaders extra_header_type classes
Governs the generation of additional headers for the named classes. The extra_header_type of CVMOffsets is for use only by classes intimately involved with the virtual machine implementation.

-v
Turns up the verbosity of the linking process. This option is cumulative. Currently up to three levels of verbosity are understood. This option is really only of interest as a debugging aid.

-g
Enables writing of data information that can facilitate Java debugging, if the information is available in the input data: line-number tables, local variable table and source file names. These tables are not written by default. This option also supresses the code inlining optimization.

-imageAttribute noPureCode
Make all byte codes writeable. By default they are declared as const. They must be writable to support breakpointing using the JVMDI debugger interface.

-f filename
Open the named file and read options from it. They are processed just as if they were substituted in the place of this option.

Opcode Transformations

Many Java bytecode instructions refer to symbolic quantities such as the offset of a field or of a method, or to a Java class. Normally, the Java Virtual Machine resolves such a reference upon first executing the instruction, and re-writes the instruction in place. The transformed instruction opcode is referred to as a "quickened" instruction, as subsequent executions of it do not need to see if resolution has taken place, but can proceed assuming it has. This yields non-ROMable Java code.

JavaCodeCompact determines the offset of every instance field and the methodtable offset of each non-static method for each class in the generated file. It requires that the complete inheritance hierarchy for each class be present in the set of classes linked. Thus it is able to quicken opcodes referring those quantities, as well as those referencing other classes in the set being processed.

The usual quickening process makes it harder to re-construct source code information from the binary program. For example, it is harder to discover name and type information for a class member given only its offset. When retention of this information is important (such as debugging using JVMDI), an alternate set of quickened instructions can be used. They can be more easily interpreted at runtime, but are somewhat slower to execute.

Java bytecodes resolved and quickened at link time are read-only and thus ROMable. Instructions referring to symbols not resolved remain un-quick, and thus writable.

A few other transformations take place during linking, including the simple inlining of very short methods.

Output

The main product of the program is a body of initialize data structures, in C, representing the classes of the input files, and their ancilliary data structures, such as Strings, the String intern table, the type table, primitive type classes and many of the array type classes referenced in the input. In addition to one or more .c files, a .h file is produced, giving forward declarations, and for use only by the other source files produced by JavaCodeCompact. It will be referred to hereafter as the forward file.

Due to the limitations of many C compilers, it is often necessary to break this output into multiple files. When the -maxSegmentSize option is give, multiple .c files are produced: one to hold shared data structures such as strings and types, and as many others are necessary, each containing no more than num_classes classes.

The names of the files produced are computed using a combination of variables and options.

See Also


 
Copyright © 2000 Sun Microsystems, Inc. All Rights Reserved.

Please send comments to: jcp-cdc-comments@eng.sun.com
Sun