Ovm 03.11.10 reviewDownload
Ovm is a tool for generating virtual machines
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.
Here are some key features of "Ovm":
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 API's that rely on native code - Ovm does not support the AWT and other API's that are non-core. Ovm depends on GNU Classpath for all of the JDK API's, 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.
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 Ovm's 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.
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.
Ovm 03.11.10 keywords