OSGi and Real Time

1. OSGi and Real Time Kelvin Nilsen, Ph.D., CTO

2. For “traditional soft real time” with J2ME • It would be nice if each OSGi bundle could: • Establish an expected memory utilization, and • An expected CPU consumption • Based on experimentation on the targeted platform to determine resource needs on this platform • And have these resource budgets “guaranteed” by the platform

3. New Standards Emerging for Safety-Critical Java • No garbage collection • Safe stack allocation • Very small memory footprint • Simplicity of run-time environment • Throughput efficiency of optimized C • We need an OSGi-like capability in this environment, but existing OSGi is too big

4. The Thread Stack Model Initially, the run-time stack (grows downward) for the main thread represents all non-immortal memory.

5. Memory for third spawned thread’s stack Memory for second spawned thread’s stack Memory for first spawned thread’s stack The Thread Stack Model The main thread may spawn additional threads, setting aside part of its own stack to represent the stack memory for the spawned threads. Any of the spawned threads may in turn carve up its stack in order to spawn “grandchildren” threads.

6. But objects residing in the parent thread’s stack below the point from which the child thread was spawned are not visible to the child thread. And outer-nested objects are not allowed to see objects residing in more inner-nested scopes. And a child thread may see scoped objects that reside in the parent thread’s stack above the point at which the child thread was spawned. Individual threads populate their run-time stacks as appropriate. Each thread’s scoped objects can see scoped objects allocated In more outer-nested scopes of the same thread. The Thread Stack Model

7. After the child threads have joined with the parent thread, their memory is fully reclaimed (and defragmented). The Thread Stack Model The parent thread is required to join with its spawned threads before returning from the context from which it spawned those threads.. Thread-3 Thread-2 Thread-1

8. Dynamic Class Loading • Classes are loaded into ThreadStack memory as scoped objects • Loaded classes may be seen only by called methods and descendent threads

9. Memory for third spawned thread’s stack Memory for second spawned thread’s stack Memory for first spawned thread’s stack Loading classes within thread stacks The main thread may dynamically load classes into its “private”scope. These loaded classes can be seen by called methods. Subsequently spawned subthreads may also see the loadedclasses. In fact, the spawned subthreads may even be instancesof a dynamically loaded NoHeapRealtimeThread subclass.

10. Memory for third spawned thread’s stack Memory for second spawned thread’s stack Memory for first spawned thread’s stack Rebudgeting memory Any thread may voluntarily release its memory and have that memory rebudgeted to serve other purposes

11. Memory for third spawned thread’s stack Second spawned thread releases its memory Memory for first spawned thread’s stack Rebudgeting memory Any thread may voluntarily release its memory and have that memory rebudgeted to serve other purposes

12. Memory for third spawned thread’s stack And this memory is divided for the stacks of fourth and fifth threads, very deterministically and very efficiently Memory for first spawned thread’s stack Rebudgeting memory Any thread may voluntarily release its memory and have that memory rebudgeted to serve other purposes

13. Cooperating HRT Components Pico HardReal-Time Execution Engine PERC Virtual Machine

14. TraditionalJava Registry TraditionalJava TraditionalJava.publish(“deviceXYZ”, x)

15. TraditionalJava Registry “Hard Real-Time Domain” HardRealTimeDomain.lookup(“deviceXYZ”)