Free ahead of time software for linux

Time::Warp is a Perl module to control over the flow of time.

SYNOPSIS

use Time::Warp qw(scale to time);

to(time + 5); # 5 seconds ahead
scale(2); # make time flow twice normal

Our external experience unfolds in 3 1/2 dimensions (time has a dimensionality of 1/2). The Time::Warp module offers developers control over the measurement of time.

API

to($desired_time)

The theory of relativity asserts that all physical laws are enforced relative to the observer. Since the starting point of time is arbitrary, it is permissable to change it. This has the effect of making it appear as if time is moving forwards or backward instanteously. For example, on some types of operating systems time starts at Wed Dec 31 19:00:00 1969 (this will likely change as we approach 2030 and with the acceptance of 64-bit CPUs).

to(time + 60*60); # 1 hour ahead

scale($factor)

Changes the speed at which time is progressing.

scale(scale * 2); # double the speed of time

Note that it is not possible to stop time or cause it to reverse since this is forbidden by the second law of thermodynamics.

CacheTable is a C++ template library that implements a very fast hash map container.
Its particularity, compared with std::hash_map and google::sparse_hash_map, is that it has a fixed size (decided it when it is created) and a random item replacement policy: in case of an "hash collision" the older item is "discarded" and replaced with the new one.
This container is ideal for implementing a caching system, when you want very fast item insertion and retrieval and you know the memory amount you want to dedicate ahead of time.
Enhancements:
- This release fixes a bug with deletion of iterator range, and work continues on more complete documentation.
- The test case has been reorganized to not require external libraries.

JavaNativeCompiler (JNC) is a Java to native compiler. The project allows AOT (ahead of time) compilation of your Java applications. With JNC, you can create real standalone native binaries (.exe on Windows) which will no longer depend on a JRE.
This is especially useful when applications have to be deployed to end-users. All vexatious problems of deploying Java applications can be solved by compiling them to native. They will be:
- Easy to deploy
No JRE dependency. Most end-users dont know what they have installed.
No more problems on how to create an executable file out of a JAR or class file.
- Hard to decompile
Java can easily be decompiled. Native compilation will protect your source code.
- Run fast from the start
No more overhead for loading a JRE.
Enhancements:
- This release fixes a couple of problems with AWT/Swing and XML.
- It also once again contains a version for Linux.
- The compiler binary downloads are smaller.

Joeq is a virtual machine and compiler infrastructure designed to facilitate research in virtual machine technologies such as Just-In-Time and Ahead-Of-Time compilation, advanced garbage collection techniques, distributed computation, sophisticated scheduling algorithms, and advanced run time techniques.
Joeq is entirely implemented in Java, leading to reliability, portability, maintainability, and efficiency. It is also language-independent, so code from any supported language can be seamlessly compiled, linked, and executed -- all dynamically.
Each component of the virtual machine is written to be independent with a general but well-defined interface, making it easy to experiment with new ideas.
Joeq is released as open source software, and is being used as a framework by researchers on five continents on topics ranging from automatic distributed virtual machines to whole-program pointer analysis.
Joeq is a virtual machine and compiler infrastructure designed to be a platform for research in compilation and virtual machine technologies. We had three main goals in designing the system. First and foremost, we wanted the system to be flexible. We are interested in a variety of compiler and virtual machine research topics, and we wanted a system that would not be specific to researching a particular area.
For example, we have interest in both static and dynamic compilation techniques, and in both type-safe and unsafe languages. We wanted a system that would be as open and general as possible, without sacrificing usability or performance.
Second, we wanted the system to be easy to experiment with. As its primary focus is research, it should be straightforward to prototype new ideas in the framework. With this in mind, we tried to make the system as modular as possible, so that each component is easily replaceable. Learning from our experience with Jalapeno, another virtual machine written in Java, we decided to implement the entire system in Java.
This makes it easy to quickly implement and prototype new ideas, and features like garbage collection and exception tracebacks ease debugging and improve productivity. Java, being a dynamic language, is also a good consumer for many of our dynamic compilation techniques; the fact that our dynamic compiler can compile the code of the virtual machine itself means that it can dynamically optimize the virtual machine code with respect to the application that is running on it. Javas object-oriented nature also facilitates modularity of the design and implementation.
Third, we wanted the system to be useful to a wide audience. The fact that the system is written in Java means that much of the system can be used on any platform that has an implementation of a Java virtual machine. The fact that Joeq supports popular input languages like Java, C, C++, Fortran, and even x86 binary code increases the scope of input programs. We released the system on the SourceForge web site as open source under the Library GNU Public License.
It has been picked up by researchers on five continents for various purposes, among them: automatic extraction of component interfaces, static whole-program pointer analysis, context-sensitive call graph construction, automatic distributed computation, versioned type systems for operating systems, sophisticated profiling of applications, advanced dynamic compilation techniques, system checkpointing, anomaly detection, secure execution platforms and autonomous systems. In addition, Joeq is now used as the basis of the Advanced Compilation Techniques class taught at Stanford University.
Joeq supports two modes of operation: native execution and hosted execution. In native execution, the Joeq code runs directly on the hardware. It uses its own run-time routines, thread package, garbage collector, etc. In hosted execution, the Joeq code runs on top of another virtual machine. Operations to access objects are translated into calls into the reflection library of the host virtual machine.
The user code that executes is identical, and only a small amount of functionality involving unsafe operations is not available when running in hosted execution mode. Hosted execution is useful for debugging purposes and when the underlying machine architecture is not yet directly supported by Joeq. We also use hosted execution mode to bootstrap the system and perform checkpointing, a technique for optimizing application startup times.
Joeq system consists of seven major parts:
- Front-end: Handles the loading and parsing of input files, such as Java class files, SUIF files, and binary object files.
- Compiler: A framework for performing analyses and optimizations on code. This includes the intermediate representation (IR) of our compiler.
- Back-end: Converts the compilers intermediate representation into native, executable code. This code can be output to an object file or written into memory to be executed. In addition, it generates metadata about the generated code, such as garbage collection maps and exception handling information.
- Interpreter: Directly interprets the various forms of compiler intermediate representations.
- Memory Manager: Organizes and manages memory. Joeq supports both explicitly-managed and garbage-collected memory.
- Dynamic: Provides profile data to the code analysis and optimization component, makes compilation policy decisions, and drives the dynamic compiler.
- Run-time Support: Provides runtime support for introspection, thread scheduling, synchronization, exception handling, interfacing to external code, and language-specific features such as dynamic type checking.

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.

BakaSub is a GTK+/Gnome video subtitling program. It supports Super Station Alpha File formats for titles. BakaSub is written entirely in ANSI C++ (using the -pedantic flag of EGCS) so it should be portable too. I aim for full Gnome compliance in BakaSub, as well as some Gnomey features (like graphics dragndrop, concurrent events, etc). Currently there are no Gnome specific features or support other than using GTK+, but it is basically a matter of turning on a flag in the Makefile. More options will be done on that later.
BakaSub was being designed directly from Kotus popular and god-like Sub Station Alpha program for Windows. Although the two programs share no actual code (they are written in very different languages, in very different environments!) I aim to have full Sub Station Alpha compatability. What does this mean for you, the user? It means that any script you create with BakaSub, you can trade with your friends who have SSA. It also means that any SSA script you receive will work perfectly out of the box (minus a few font differences) and any SSA script you edit will retain 100% of its previous data (no loss of data after going through BakaSub).
In modern versions of BakaSub (about the last two) I have made a decision to break away from SSAs user interface, however, because I think that it limits the user in some ways that are understandable for SSAs implementation, but which I have the opportunity to do away with because of the speed of C++. For example, SSA (at least as of version 3.x) displays a single subtitle for you to look at in the preview window, while BakaSub actually shows a scale-model preview with all concurrent subtitles and graphics.
Enhancements:
- Frame slider is now more functional. I figured out the proper hack to reconfigure a slider at runtime (grr!). Some more work is needed here though.
- SSA 3.x save support is now in, in its basic form. Some stuff probably doesnt work right. Dont bet the farm on this just yet =). To use it use Save As.... Save doesnt do anything yet.
- During SSA 3.x loads, styles that exist in the local style library (e.g., *Default vs Default) are no longer loaded. I dont know if this is the proper behavior but for now thats how it works.
- The very beginnings of Sconv integration are in there.
- bttv_ttf has been reworked to be a full multithreaded application. This means that there are now two threads during its execution: the frame engine, which is producing frames ahead of time, and the display engine, which is doing exquisite timing and data capture, and letting the frame engine know when to make another frame. The display engine has POSIX realtime priorities set if youre root, and the frame engine has normal priorities. This works
- much better on my uniprocessor system, and on dual or greater, it will be even better.
- The plug-in architecture is now in place (at least an early version). This will probably undergo some more changes before I leave it to start turning various things into plug-ins and normalizing the plug-in interfaces. There are also two brand new plug-ins, derived from the old statically linked ones, the SSA loader and the external rendering playback device.
- A new debug level has been added, DBG_ERROR. This is for fatal errors that cause a routine to fail and return, as opposed to DBG_WARNING, which means that the results will probably be invalid.