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

2. 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. 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. 4 The Thread Stack Model Initially, the run-time stack (grows downward) for the main thread represents all non-immortal memory.

5. 5 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. Memory for first spawned thread’s stack Memory for second spawned thread’s stack Memory for third spawned thread’s stack Any of the spawned threads may in turn carve up its stack in order to spawn “grandchildren” threads.

6. 6 The Thread Stack Model 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. 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. 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.

7. 7 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-1 Thread-3 Thread-2 After the child threads have joined with the parent thread, their memory is fully reclaimed (and defragmented).

8. 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. 9 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. Memory for first spawned thread’s stack Memory for second spawned thread’s stack Memory for third spawned thread’s stack Subsequently spawned subthreads may also see the loaded classes. In fact, the spawned subthreads may even be instances of a dynamically loaded NoHeapRealtimeThread subclass.

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

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

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

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

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

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