java [ Java options ] JavaCodeCompact [ options ] filename ...
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.
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.
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.
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.
CVMOffsets
is for
use only by classes intimately involved with the
virtual machine implementation.
const
. They must be writable to support
breakpointing using the JVMDI debugger interface.
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.
Copyright © 2000
Sun Microsystems, Inc.
All Rights Reserved.
Please send comments to: jcp-cdc-comments@eng.sun.com |
![]() |