Free jvm software for linux

B::JVM::Utils is a Perl module that contains utility functions for B::JVM.

SYNOPSIS

use B::JVM::Utils qw(method1 method2);

This package is a set of utilties that are useful when compiling Perl to the JVM architecture. They are a hodgepodge of utilties that dont really fit anywhere else.

B::JVM::Jasmin::Utils Package Variables

$VERSION

Version number of B::JVM::Utils. For now, it should always match the version of B::JVM::Jasmin

@EXPORT_OK

All the methods that one can grab from B::JVM::Utils.

@EXPORT

We dont export anything by default.

Modules used by B::JVM::Utils

Carp

Used for error reporting

Methods in B::JVM::Utils

B::JVM::ExtractMethodData

usage: B::JVM::ExtractMethodData(METHOD_STRING)

Takes a string that is believed to a valid method string for a JVM method, and if it is a valid method string, returns a hash reference that looks like: { methodName => NAME_OF_THE_METHOD, returnType => TYPE_ID_OF_RETURN_TYPE, argumentTypes => [ ARGUMENT_1_RETURN_TYPE_ID, ARGUMENT_1_RETURN_TYPE_ID, ... ] } An undefined value is returned if the method string is not valid.

B::JVM::Utils::IsValidMethodString

usage: B::JVM::Utils::IsValidMethodString(METHOD_STRING)

Takes a string that is believed to a valid method name for a JVM method, and returns a true iff. the METHOD_STRING is a valid JVM method name

B::JVM::Utils

usage: B::JVM::Utils:IsValidTypeIdentifier(TYPE_ID)

Takes a string that is believed to a valid type identifitier name on the JVM, and returns a true iff. the TYPE_ID is a valid JVM type identifier

Java::Build::JVM is a Perl module that starts one JVM for compiling.

SYNOPSIS

use Java::Build::JVM;

my $compiler = Java::Build::JVM->getCompiler();
$compiler->destination("some/path");

$compiler->classpath("some/pathto/jar.jar:some/other/path/javas");
$compiler->append_to_classpath("something/to/add/to/previous/path");

$compiler->compile([ qw(list.java of.java programs.java) ]);

This class starts a single JVM which it then helps you contact for compiling tasks. This is the most important feature of the popular Ant build tool. Using this class, you can effectively replace Ant, and its notoriously unmaintainable build.xml files, with Perl scripts. Most Ant tasks are already built in to Perl with far more flexibility than Ant provides.

To obtain a compiler, use this module, then call getCompiler. It has that name to prevent conflicts with the Java new keyword.

Once you have a compiler, you may change the destination of subsequent compiles from the location of the source files to a directory of your choice using the destination method. You can create or append to a classpath with the classpath or append_to_classpath methods. Note that your CLASSPATH environment variable still works in its usual way.

Finally, once you have the destination and classpath set, you can compile a list of files by passing them to the compile method. Note that they need to be in an array reference (if you dont know what that means, put the list in square brackets).

Note that you must have tools.jar in your CLASSPATH when you run your script. Without that, JVM.pm will not be able use Inline::Java. The classpath you use inside the script may be the same or different than your environment variable, depending on how you use the classpath and append_to_classpath methods.
Since Sun has, in its finite wisdom, chosen to deprecate the compiling methods that javac uses, there will be one warning for each time you call compile. It will say something like this:

Note: sun.tools.javac.Main has been deprecated.
1 warning

This warning is not a problem in Java 1.4.

B::JVM::Jasmin::Emit is a package used by B::JVM::Jasmin to emit Jasmin syntaxed file.

SYNOPSIS

use B::JVM::Jasmin::Emit;

my $emitter = new B::JVM::Emit(FILEHANDLE);

# ...
$emitter->DIRECTIVE_NAME([@ARGS]);
# ...
$emitter->OPCODE_NAME([@ARGS]);
# ...
$emitter->OPCODE_NAME([@ARGS]);

This class is used emit JVM assembler code in Jasmin syntax. Each method one can use is either an opcode or a directive supported by Jasmin syntax.

B::JVM::Jasmin::Emit Package Variables

$VERSION

Version number of B::JVM::Jasmin::Emit. For now, it should always match the version of B::JVM::Jasmin

@EXPORT_OK

All the methods that one can grab from B::JVM::Jasmin::Emit

@EXPORT

We dont export anything by default.

Modules used by B::JVM::Jasmin::Emit

Carp

Used for error reporting

B::JVM::Utils

Used to get needed utility functions, such as ExtractMethodData and IsValidMethodString

Methods in B::JVM::Jasmin::Emit

B::JVM::Jasmin::Emit::new
usage: B::JVM::Emit::new(FILEHANDLE, [SOURCE_FILE_NAME])
Creates a new object of the class. It assumes that FILEHANDLE is a lexically scoped file handle open for writing, and that SOURCE_FILE_NAME that should be used for a source directive. SOURCE_FILE_NAME is optional, but may annoys someone firing up your code in the Java debugger.
B::JVM::Emit::Jasmin::_clearMethodData()
usage: $jasminEmitter->_clearMethodData()
Clear out the method data elements of the Jasmin emitter
B::JVM::Emit::Jasmin::source
usage: B::JVM::Emit::Jasmin::source(SOURCE_FILE_NAME)
Emits the source file name directive.
B::JVM::Emit::Jasmin::comment
usage: B::JVM::Emit::Jasmin::comment($methodName, $commentString)
Puts $commentString in a comment in the file, in the code for method $metohdName.
B::JVM::Emit::Jasmin::super
usage: B::JVM::Emit::Jasmin::super(CLASS_NAME)
sends class directive, using CLASS_NAME, to the output file
B::JVM::Emit::Jasmin::class
usage: B::JVM::Emit::Jasmin::class(ACCESS_SPEC, CLASS_NAME)
sends class directive, using CLASS_NAME to the ACCESS_SPEC, to the output file
B::JVM::Emit::Jasmin::interface
usage: B::JVM::Emit::Jasmin::interface(ACCESS_SPEC, INTERFACE_NAME)
sends interface directive, using INTERFACE_NAME to the ACCESS_SPEC, to the output file
B::JVM::Emit::Jasmin::implements
usage: B::JVM::Emit::Jasmin::implements(CLASS_NAME)
sends implements directive, using CLASS_NAME to the output file
B::JVM::Emit::Jasmin::labelCreate
usage: $emitter-labelCreate($methodName, $labelNameRequested)>
In method, $methodName, creates a new label, whose name will "resemble" $labelNameRequested. This label is not actually sent to the output, that must be done later with $emitter-labelSend($methodName, $value)>.
Note that the value returned from this method is the actual label name assigned and will only "resemble" (i.e., not match exactly) the $labelNameRequested.
B::JVM::Emit::Jasmin::labelSend
usage: $emitter-labelSend($methodName, $labelName)>
Send a label, $labelName, to the output of method, $methodName.
This label must be valid label previously returned from $emitter-labelCreate($methodName, $someValue)>.
B::JVM::Emit::Jasmin::field
usage: B::JVM::Emit::Jasmin::field(ACCESS_SPEC, FIELD_NAME, TYPE, [VALUE])
sends field directive, using the arguments given, to the output file
B::JVM::Emit::Jasmin::methodStart
usage: $emitter->methodStart(METHOD_NAME, ACCESS_SPEC, [STACK_SIZE])
sends method directive and other directives needed to start up a new method. Also sets the current method for the emitter. STACK_SIZE is optional. However, a stack size is always set to a default value (currently 256), because if it is not set, a number of problems occur with the stack.
B::JVM::Emit::Jasmin::methodCreateLocal
usage: $emitter->methodCreateLocal(METHOD_NAME, VARIABLE_NAME_REQUEST, VARIABLE_TYPE, [LABEL1], [LABEL2])
Creates a local of type VARIABLE_TYPE, with a given name in method, METHOD_NAME. If LABEL1 is given, LABEL2 must be given, and vice versa.
If the labels are given, then the variable is only valid between those two labels in the resulting assembler source.
methodCreateLocal attempts to give a variable name that "resembles" VARIABLE_NAME_REQUEST. If the labels are given, it is guaranteed that the variable name will "resemble" the VARIABLE_NAME_REQUEST.
If the labels are not given, it is very likely that an old local variable of the same type will be returned.
The actual variable name given will be returned. It is imperative that the user of methodCreateLocal use this variable name, and not VARIABLE_NAME_REQUEST, for obvious reasons.
B::JVM::Emit::Jasmin::methodFreeLocal
usage: $emitter->methodFreeLocal(METHOD_NAME VARIABLE_NAME)
Indicates that the local, VARIABLE_NAME, in method, METHOD_NAME, is no longer in use. It is not required that locals be freed in this manner, however, many, many locals can be allocated unnecessarily if this is not done.
B::JVM::Emit::Jasmin::methodEnd
usage: $emitter-methodEnd($method, [$debug])>
Finishes up a method, $method, that is currently being emitted. If $debug is defined and is true, then ".line" directives will be put into the output for debugging purposes.
B::JVM::Emit::Jasmin::astore
usage: $emitter->astore([METHOD, VARIABLE])
Emits an "astore" instruction, using the VARIABLE name in METHOD given, if one is given. If VARIABLE is given, it is looked up in variables created with B::JVM::Emit::Jasmin::methodCreateLocal() for the given method, METHOD.
B::JVM::Emit::Jasmin::invokevirtual
usage: $emitter->invokevirtual(METHOD_IN, METHOD_INVOKED)
Emits an "invokevirtual" instruction to invoke METHOD_INVOKED in the code for METHOD_IN
B::JVM::Emit::Jasmin::ifne
usage: $emitter-ifne($methodName, $labelName)>
Emits an "ifne" instruction with argument, $labelName in the code for method, $methodName.
This label, $labelName must be valid label previously returned from $emitter-labelCreate($methodName, $someValue)>.
B::JVM::Emit::Jasmin::ifeq
usage: $emitter-ifeq($methodName, $labelName)>
Emits an "ifeq" instruction with argument, $labelName in the code for method, $methodName.
This label, $labelName must be valid label previously returned from $emitter-labelCreate($methodName, $someValue)>.
B::JVM::Emit::Jasmin::aload
usage: $emitter->aload([METHOD, VARIABLE])
Emits an "aload" instruction, using the VARIABLE name in METHOD given, if one is given. If VARIABLE is given, it is looked up in variables created with B::JVM::Emit::Jasmin::methodCreateLocal() for the given method, METHOD.
B::JVM::Emit::Jasmin::invokestatic
usage: $emitter->invokevirtual(METHOD_IN, METHOD_INVOKED)
Emits an "invokestatic" instruction to invoke METHOD_INVOKED in the code for METHOD_IN
B::JVM::Emit::Jasmin::iconst
usage: $emitter->iconst(METHOD, VALUE)
Emits an "iconst" instruction, using the value of VALUE for the constant, in the method named METHOD.
B::JVM::Emit::Jasmin::istore
usage: $emitter->istore([METHOD, VARIABLE])
Emits an "istore" instruction, using the VARIABLE name in METHOD given, if one is given. If VARIABLE is given, it is looked up in variables created with B::JVM::Emit::Jasmin::methodCreateLocal() for the given method, METHOD.
B::JVM::Emit::Jasmin::iload
usage: $emitter->iload([METHOD, VARIABLE])
Emits an "iload" instruction, using the VARIABLE name in METHOD given, if one is given. If VARIABLE is given, it is looked up in variables created with B::JVM::Emit::Jasmin::methodCreateLocal() for the given method, METHOD.
B::JVM::Emit::Jasmin::iand
usage: $emitter->iand([METHOD])
Emits an "iand" instruction, in METHOD given, if one is given.
B::JVM::Emit::Jasmin::pop
usage: $emitter->pop([METHOD])
Emits an "pop" instruction, in METHOD given, if one is given.
B::JVM::Emit::Jasmin::getstatic
usage: $emitter->getstatic(METHOD_IN, FIELD, TYPE)
Emits an "getstatic" instruction for the field, FIELD, of type, TYPE in the code for METHOD_IN
B::JVM::Emit::Jasmin::ldc
usage: $emitter->ldc(METHOD_IN, VALUE)
Emits an "ldc" instruction with the value of VALUE, in the method METHOD_IN.
B::JVM::Emit::Jasmin::newObject
usage: $emitter->newObject(METHOD_IN, CLASS)
Emits an "new" instruction for the class, CLASS in the body for the method, METHOD_IN. CLASS must be a valid class name.
B::JVM::Emit::Jasmin::invokespecial
usage: $emitter->invokespecial(METHOD_IN, METHOD_INVOKED)
Emits an "invokespecial" instruction to invoke METHOD_INVOKED in the code for METHOD_IN
B::JVM::Emit::Jasmin::dup
usage: $emitter-dup($method)>
Emits an "dup" instruction in the code for the method, $method
B::JVM::Emit::Jasmin::swap
usage: $emitter-swap($method)>
Emits an "swap" instruction in the code for the method, $method
B::JVM::Emit::Jasmin::gotoLabel
usage: $emitter-gotoLabel($methodName, $labelName)>
Emits an "goto" instruction with argument, $labelName in the code for method, $methodName.
This label, $labelName must be valid label previously returned from $emitter-labelCreate($methodName, $someValue)>.
B::JVM::Emit::Jasmin::returnVoid
usage: $emitter->returnVoid(METHOD_IN)
Emits an "return" instruction in the code for method, METHOD_IN.
B::JVM::Emit::Jasmin::iinc
usage: $emitter-iinc($method, $variable, $amount)>
Emits an "iinc" instruction, using the $variable name in the method, $method. The variable, $variable must have one previously returned from methodCreateLocal($method, ...) that has not been freed with methodFreeLocal($method, ...) yet.
$amount is the integer amount to increment $variable by.
B::JVM::Emit::Jasmin::bipush
usage: $emitter-bipush($method, $value)>
Emits an "bipush" instruction, into the method, $method using the value of $value. Note that an "iconst" or an "iconst_m1" instruction is emitted if the $value is the range where "iconst" will work.
B::JVM::Emit::Jasmin::aastore
usage: $emitter-aastore($method)>
Emits an "aastore" instruction, into the method, $method.
B::JVM::Emit::Jasmin::isub
usage: $emitter-isub($method)>
Emits an "isub" instruction, into the method, $method.
B::JVM::Emit::Jasmin::nop
usage: $emitter-nop($method)>
Emits a "nop" instruction, into the method, $method.
B::JVM::Emit::Jasmin::aaload
usage: $emitter-aaload($method)>
Emits an "aaload" instruction, into the method, $method.
B::JVM::Emit::Jasmin::anewarray
usage: $emitter-anewarray($method, $type)>
Emits an "anewarray" instruction, into the method, $method. The new array will be of type $type. The method will fail if $type is not a valid JVM type identifier.

JamVM is a new Java Virtual Machine which conforms to the JVM specification version 2 (blue book). In comparison to most other VMs (free and commercial) it is extremely small, with a stripped executable on PowerPC of only ~130K, and Intel 100K.
However, unlike other small VMs (e.g. KVM) it is designed to support the full specification, and includes support for object finalisation, the Java Native Interface (JNI) and the Reflection API.
Main features:
- Uses native threading (posix threads). Full thread implementation including Thread.interrupt()
- Object references are direct pointers (i.e. no handles)
- Supports class loaders
- Efficient thin locks for fast locking in uncontended cases (the majority of locking) without using spin-locking
- Two word object header to minimise heap overhead (lock word and class pointer)
- Execution engine supports basic switched interpreter and threaded interpreter, to minimise dispatch overhead (requires gcc value labels)
- Stop-the-world mark and sweep garbage collector
- Thread suspension uses signals to reduce suspend latency and improve performance (no suspension checks during normal execution)
- Full object finalisation support within the garbage collector (with finaliser thread)
- Garbage collector can run synchronously or asynchronously within its own thread
- String constants within class files are stored in hash table to minimise class data overhead (string constants shared between all classes)
- Supports JNI and dynamic loading for use with standard libraries
- Uses its own lightweight native interface for internal native methods without overhead of JNI
- JamVM is written in C, with a small amount of platform dependent assembler, and is easily portable to other architectures.
Enhancements:
- Re-worked thread suspension enable/disable code
- implemented a fast enable/disable suspend mechanism for critical code sections, which is now used in hash table access and heap allocation :
- much faster object allocation
- much faster primitive array allocation
- faster string interning
- removed some minor potential (as yet unseen) race conditions
- Integrated all outstanding patches
- generics branch patch, implementing VMClass.isEnum(), isAnnotation() and isSynthetic()
- Boot library path patch (support for system property gnu.classpath.boot.library.path)
- Enabled different min/max heap values for each architecture
- ARM values are back to the defaults for JamVM 1.2.5. Default max heap of 128Mb is too large for typical embedded ARM systems.
- Fixed the new compiler warnings from gcc-4.0 (under Mac OS X) related to char/signed char usage.
- Fixed compiler error on gcc-4.0 under Mac OS X 10.4 (duplicate definitions of wait).
- Fixed rare, potential dead-lock in direct.c when preparing methods
- Fixed a bug in VMClassLoader.defineClass(), where offset or length is wrong.
- Fixed bug in DCONST_1 on mixed-endian ARM architectures (this bug was fixed in JamVM 1.2.2 but it crept back in, due to the new interpreter in JamVM 1.2.5).
- Improved thread dump (produced via SIGQUIT, or ctrl-).
- Several other minor bug-fixes, and code tidy-ups.

TIJmp is a memory profiler for java. TIJmp is made for java/6 and later, it will not work on java/5 systems. If you need a profiler for java/5 or earlier try the jmp profiler.
TIJmp is written to be fast and have a small footprint, both memory- and cpu-wise. This means that the jvm will run at almost full speed, until you use tijmp to find some information.
TIJjmp uses C code to talk to the jvm and it uses swing to show the the tables of information. So tijmp is written in C (using jvmti and jni) and Java.
TIJmp runs in the same jvm as the program being profiled. This means that it can easily get access to all things jvmti/jni has to offer.
This project is distributed under the General Public License, GPL.
Enhancements:
- Owner information now shows correct field names for static variables and array indexes show the correct position.
- The classpath setup was improved.
- It now installs files in the correct Linux directories.

SableVM is a robust, extremely portable, efficient, and specifications-compliant Java virtual machine that aims to be easy to maintain and to extend.
It features a state-of-the-art and efficient interpreter engine. Its source code is very accessible and easy to understand. It also has many robustness features that have been the object of careful design.
SableVM is a clean-room implementation of the publicly available specifications.
Main features:
- Clean code, with minimal duplication, thanks to a set of easy-to-use indent-friendly m4 macros.
- Modularity, making it ideal for research into different implementations of VM components.
- Standards compliance (C, POSIX, JVM, JNI, JLS).
- Three different interpreter engines, of which the basic switch interpreter is perfect for debugging, and the inlined-threaded interpreter is competitively fast. See [Execution Engines]?.
- A nice development environment, thanks to the above features. New contributors can start grokking it easily.
- Use of the latest GNU Classpath. We frequently synchronize with the GNU Classpath CVS.
- Portability (record time is 1 hour for a new port).
- Permissive LGPL license.
- A retargettable just-in-time compiler, SableJIT, which currently runs on ppc, x86, and sparc. The initial implementation is almost ready.
- Proper implementation of the invocation interface, which makes it possible to execute Java code from an application written in a different language. SableVM was designed so that extending it to follow the full specifications is straightforward, and allows for many virtual machines to be created, run, and destroyed within a single process (still not fully complete). This is something that the official Sun implementation does not provide.

Ovm is a tool for generating virtual machines. Ovm includes a variety of compilers, garbage collectors, and threading systems that can be used to create a free-standing VM.
This VM can (and currently must) be specialized to a particular application. Ovm is currently able generate virtual machines for ordinary Java programs, and programs written to the Real-time Specification for Java.
Main features:
- dynamic loading - Like many ahead-of-time compilers for real-time/embedded systems, the Ovm does not support dynamic loading of classes. In the future we expect to support this via some form of mixed-mode operation and/or using the JIT compiler.
- weak references and finalization - There is no support for weak references and heap finalizers are never run. Finalizers for objects allocated in RTSJ scoped memory are run.
- Non-core JDK APIs that rely on native code - Ovm does not support the AWT and other APIs that are non-core. Ovm depends on GNU Classpath for all of the JDK APIs, but must provide its own special code to replace all native calls.
- JNI support - Ovm does not support JNI and it is not planned at the present. Much native code is replaced in Ovm by Java code operating in what we term the "executive domain". There are ways to provide additional native code support but there are highly specialized and not intended for general application use.
Code using dynamic loading, native calls or finalizers will need to be adapted to work with Ovm.
The implementation of the real-time APIs is also incomplete - see the package.html file in src/syslib/user/ovm_realtime/javax/realtime for details.
This is a BETA release. Ovm still has known bugs that can lead to unexpected behavior, especially when migrating large applications to Ovm.
Usage
Ovm is regularly tested on Linux/x86, Linux/ppc, and OS X/ppc. The JIT only works on x86. Ovm requires a Sun, IBM, or Apple release of Java 1.4 and gcc 3.x to build. 256 MB of main memory are also required, 1 GB are recommended.
In order to run Java applications under Ovm, it is strongly recommended that you compile the applications against Ovms version of the JDK (which is based on GNU classpath). This is the easiest way to ensure that you do not rely on library functionality that is not available. Instructions on how to compile Java code against the Ovm JDK are in the file TUTORIAL. The TUTORIAL also describes how to run the SPEC JVM and the real-time benchmarks.
Also note that all class files must have been compiled to the format defined by the javac -target 1.1 setting. This restriction will be removed in the future.
At this point in time, Ovm always requires whole-world compilation of the application. Ovm has three execution backends, an interpreter, a JIT and J2C which is a front-end to GCC. Both the interpreter and the JIT are intended to be used in conjunction with dynamic loading in the future. At this stage, building Ovm with these configurations is only useful for development purposes. All benchmarking should always be done with the J2C configuration with gcc-3.4.
Version restrictions:
- The Ovm program (gen-ovm), may very rarely hang after calling out to a subprocess. This appears to be a bug in Linux implemenations of Java 1.4, and occurs more frequently with Blackdown Java distributions than Sun. Ovm attempts to detect and work around the problem, but this code is extremely difficult to test. One simple trick that sometimes unhangs things is to stop the process (use -Z) and then restart it using fg.

Java::Build is a family of modules which you can use instead of Ant.

SYNOPSIS

use Java::Build::JVM; # access to the javac compiler in one jvm
use Java::Build::Tasks; # some helpful methods similar to Ant tasks

my $source_files = build_file_list(
BASE_DIR => $some_path,
INCLUDE_PATTERNS => [ qr/.java$/ ],
);
my $dirty_sources = what_needs_compiling(
SOURCE_FILE_LIST => $source_files,
);
if (@$dirty_sources) {
my $compiler = Java::Ant::JVM->getCompiler();
$compiler->destination($base_dir);
$compiler->classpath($base_dir);
$compiler->compile($dirty_sources);

my $class_files = build_file_list(
BASE_DIR => $some_path,
INCLUDE_PATTERNS => [ qr/.class$/ ],
EXCLUDE_PATTERNS => [ qr/Test/ ],
EXCLUDE_DEFAULTS => 1,
STRIP_BASE_DIR => 1,
);
jar(
JAR_FILE => $jar_file_name,
FILE_LIST => $class_files,
BASE_DIR => $some_path,
);
}

ABSTRACT

This family of modules helped me move away from Ant to a proper scripting language, namely Perl. With it you can use a single JVM for compiling your java programs. It provides many useful methods to help you build lists of files, package them with jar, etc. Currently the modules are unix centric. If you make them work elsewhere, please send in patches.