Provides real-time contexts for higher performance and higher predictability of Java bytescode execution.

The rationale for this package is:

• Allocating/Initializing memory is not praticularly fast.
• Garbage collection can occur only when allocating memory.

Therefore, if "new" objects are ready to be used, either because they have been recyled (PoolContext) or they have been preallocated (PredictiveContext), code execution:

1. Is faster (e.g. 512 bits immutable integers operations are up to 6x faster)!
2. Is not interrupted by garbage collection (more predictable scheduling).
3. Has no assignment constraint as all objects originate from the heap (Ref. RTSJ assignment rules where heap objects cannot refer to scoped objects).

To enter a particular context, an application may either call the appropriate enter{Runnable) static method or call the execute{Runnable) method on the context object (when contexts are being reused or shared). The following illustrates how a PoolContext accelerates repetitive calculations on multiple inputs:

      final Matrix[] inputs = ...;
      final Matrix[] results = new Matrix[...]; // Where to store the results.
      PoolContext.enter(new Runnable() {
           public void run() {
               for (int i=0; i < inputs.length; i++) {
                   Matrix result = inputs[i].inverse(); // Some functions of inputs and/or previous results
                                                        // (create a lot of temporary/intermediate objects).
                   result[i] = HeapContext.copy(result); // Copies the result to the heap context (where it is safe).
                   ((PoolContext)Context.current()).recycle(); // Reuses all temporary objects which have been allocated.
               }
           }
      });
      

Note: PoolContext high performance is not only due to object reuse, but also to the CPU internal cache (hits are a lot more frequent when objects are being reused).

Real-time facility FAQ:

1. PoolContext or PredictiveContext which one should I use?

   PredictiveContext are often recommended. They are completly safe (as safe as the default JVM Heap context) and they increase responsiveness as tedious memory allocation and garbage collection are moved out of the way. Typically, they are used for the processing of asynchronous events (quicker processing with no GC interruption).

   They are cases where PoolContext makes senses. For example, if you perform repetitive calculations generating a lot of temporary objects (e.g. matrix calculations above). Using a PoolContext ensures that most of the CPU is used to perform the actual task and not maintenance tasks such as memory allocation and garbage collection.

   Finally, contexts can be nested. It is thererefore possible to execute event processing within a PredictiveContext and if this processing involves heavy calculations, these calculations can be executed locally within a PoolContext, for optimal performance and safety!

2. Can I use the real-time facility with the Java core library?

   Yes, although these library calls will not execute faster (Java library always uses the heap context). Nonetheless, you may accelerate dynamic instantiations of Java library classes using an object factory. For example:

           private static final ObjectFactory STRING_BUFFER_FACTORY
               = new ObjectFactory() {
                   protected Object newObject() {
                       return new StringBuffer();
                   }
               };
           

   Then STRING_BUFFER_FACTORY.object() returns a new, a preallocated or a recycled instance according to the current context.

   Note: JADE's classes (e.g. math, physics) use object factories internally, and therefore are 100% real-time compliant.

3. What performance gain can I expect by using a real-time context?

   The cost of allocating on the heap is somewhat proportional to the size of the object being allocated. By avoiding or postponing this cost you can drastically increase the execution speed. The largest objects benefit the most. For example, our real-time String (StringRT) can be several order of magnitude faster than java.lang.String or even java.lang.StringBuffer (even java.lang.StringBuffer requires memory allocation and the larger the buffer, the longer it takes).

4. Virtual Machine with concurrent garbage collection are becoming more and more popular. Do we still need a real-time facility?

   Concurrent garbage collection is a perfect complement to JADE real-time facility (Ref. New Hotspot^TM JVM). In particular, without preemptable garbage collection we cannot ensure that periodic real-time threads start on-time.

   For these real-time threads, the advantage of the facility are twofold:

   • They execute faster. Objects have already been allocated and initialized (increase responsiveness).
   • PoolContext don't generate garbage and therefore reduce the clean-up effort by the system (maximize CPU efficiency).

   Unlike, the Real-Time Specification for Java (RTSJ) whose memory model becomes obsolete with the coming of concurrent garbage collection (who wants to use a slower memory model to achieve predictability when predictability can be achieved without?). I expect that the "turbo" effect provided by our real-time facility will attract more and more real-time applications. Especially when preemptable garbage collection makes Java a satisfactory platform for real-time systems.

5. Why this real-time facility is not part of the core Java library?

   Indeed, it would be nice if standard JVMs supported real-time contexts (no need for factory methods, core library would execute faster, java.lang.Thread could have a direct reference to the current context for optimal performance, etc.). This change would be backward compatible as the default context is the JVM Heap context and it would not require any change to the Java bytescode specification.

   If SUN^TM is interested, I am disposed to transfer any intellectual or property rights to them at no cost.