1. Doing Firm-Real-Time With J2SE APIs Delvin Defoe Center for Distributed Object Computing Department of Computer Science and Engineering Washington University By Kelvin Nilsen, CTO, NewMonics November 14, 2003

2. Friday November 14, 2003Delvin Defoe 2 Firm real-time vs Soft real-time  Soft real-time “Qué será será”  Whatever will be, will be

3. Friday November 14, 2003Delvin Defoe 3 Firm real-time vs Soft real-time  Firm real-time Disciplined development in which software engineers carefully analyze  Deadlines  Resource requirements  schedulability

4. Friday November 14, 2003Delvin Defoe 4 Firm real-time vs Hard real-time  Hard real-time Resource requirements are determined using theoretical analysis Proven through Mathematical analysis to meet all deadlines

5. Friday November 14, 2003Delvin Defoe 5 Firm real-time vs Hard real-time  Firm real-time Resource requirements are determined empirically  Measure behavior of individual components  This provides statistical confidence BUT no absolute guarantees

6. Friday November 14, 2003Delvin Defoe 6 Real-Time Specification for Java  RTSJ is a set of extensions that can be combined with any existing Java platforms – J2ME, J2SE, J2EE  Allows development of real-time software in Java

7. Friday November 14, 2003Delvin Defoe 7 Limitations of RTSJ  RTSJ Implementations run only with J2ME and only with LINUX OS  RTSJ-style RT threads Restricted to a set of the J2ME libraries Cannot use automatic GC Must adhere to strict memory usage guidelines to obtain RT threading behavior

8. Friday November 14, 2003Delvin Defoe 8 Limitations of RTSJ – cont’d  RTSJ developers cannot invoke off- the-shelf Java software components from their RT threads  RT RTSJ components are generally not portable across OS or between different compliant RTSJ implementations

9. Friday November 14, 2003Delvin Defoe 9 Alternative to RTSJ - PERC  A clean room implementation of the J2SE standards  It supports J2SE libraries except AWT and Swing  Targeted to developers attracted to the high-level benefits of Java  Has RT requirements from 1 to 10+ ms

10. Friday November 14, 2003Delvin Defoe 10 PERC Virtual Machine features  Allows each implementation to define basis for RT development  Number of priorities  Synchronization semantics  Wait queue ordering  Library compatibility

11. Friday November 14, 2003Delvin Defoe 11 PERC Virtual Machine features  Allows each implementation to define basis for RT development  Workload admission test algorithms  RT scheduling  I/O interruption semantics

12. Friday November 14, 2003Delvin Defoe 12 More PERC VM features  Run-time system controls scheduling of Java threads to ensure consistent fixed- priority dispatching and inheritance across all platforms  Offers paced RT GC with high reliability achieved through accurate scanning and automatic defragmentation of memory heap  Delivers of Java’s WORA

13. Friday November 14, 2003Delvin Defoe 13 Implementation Choices and Semantic Guarantees  Real-Time garbage Collection  Threading Behavior and Priority Inheritance  Improved Timer Services  The VM Management API

14. Friday November 14, 2003Delvin Defoe 14 Real-Time Garbage Collection  Requirements that must be satisfied by any RT GC The collection task must be quickly ‘preemptable’. Typical VMs require 10s of seconds of CPU time to perform a complete GC pass For RT systems that must dynamically allocate memory (under RT constraints) the GC progress must be paced against the applications ongoing need for memory allocations.  Requires that GC bounded and incremental so that after preemption GC resumes where left off

15. Friday November 14, 2003Delvin Defoe 15 PERC GC  Mostly stationary Garbage Collection Divides efforts into 1000s of small uninterruptible increments of work When GC resumes following preemption by a higher priority application thread, it resumes where it left off

16. Friday November 14, 2003Delvin Defoe 16 Incremental Copying garbage Collection ABC C’B’A’ From-space To-space Relocated ReservedNew Objects B and C are relocated so their valid copies are B’ and C’

17. Friday November 14, 2003Delvin Defoe 17 Incremental Mark-and-Sweep GC  Mark Phase Mark each reachable object by linking it onto scan list GC repeatedly removes leading object, L, from scan-list by advancing scan-list header pointer GC scans each of L’s pointer fields in order and marks the objects it references

18. Friday November 14, 2003Delvin Defoe 18 Incremental Mark-and-Sweep GC  Mark Phase GC leaves scan link field of L unchanged to remember L has been marked Scanning of individual objects is incremental Mark phase ends when no more objects on scan list

19. Friday November 14, 2003Delvin Defoe 19 Incremental Mark-and-Sweep GC  Sweep phase Sweep through memory from low to high address For each address examined GC knows that it is either  Start of marked object  Start of unmarked object or  start of a free segment

20. Friday November 14, 2003Delvin Defoe 20 Incremental Mark-and-Sweep GC  Sweep phase Unique bit patterns in object headers differentiate those address types Header info. also identifies the size of each object, enabling process to skip over internals of memory segments

21. Friday November 14, 2003Delvin Defoe 21 Sweep phase  Treats each situation differently If looking at marked object it clears the mark field for next GC pass If looking at free segment it coalesces it with previous object (if that object is a free segment) If looking at unmarked object it converts it into a free segment and coalesces it with previous object Coalescing is done in constant time

22. Friday November 14, 2003Delvin Defoe 22 Problem with incremental M/S GC  Application threads that preempt GC may rearrange relationship between objects before relinquishing to GC This can potentially confuse interrupted GC  Solution: Application thread executes a write barrier If GC was marking when it was preempted, the application thread will automatically mark referenced object each time it overwrites a pointer field

23. Friday November 14, 2003Delvin Defoe 23 Mostly Stationary Garbage Collection  Hybrid of Incremental Copying and Incremental Mark-and- Sweep GC  Divides memory allocation pool into multiple equal-sized regions  At start of each GC pass selects two regions to serve as from-space and to-space These regions defragmented using incremental Copying technique  Unused memory in other regions is reclaimed using Incremental M/S technique which does not relocate objects

24. Friday November 14, 2003Delvin Defoe 24 Pacing of Garbage Collection  Attribute unique to PERC GC  Total effort required to complete GC is bounded by a configuration-dependent constant, regardless of how much memory has been recently allocated or discarded, and independent of how many times the GC is preempted by the application  This enables straightforward scheduling of GC to periodically reclaim all of the dead memory in the system  VM API allows GC scheduling parameters to be adjusted on the fly to accommodate changes in system workload – Garbage collection pacing

25. Friday November 14, 2003Delvin Defoe 25 Threading Behavior and Priority Inheritance  PERC threads behave the same on all platforms  PERC VM implements sync. lock not OS  PERC VM takes full control over which PERC thread at any instant  Support priority inheritance

26. Friday November 14, 2003Delvin Defoe 26 Improved Timer Services  PERC VM provides programmers with precise control over time-constrained Java Software components com.newmonics.util.Timer class offers different semantics from java.util.Timer  Notion of time is not affected by OS RT clock drifts or modified by human operators  Notion of time is maintained internal to PERC VM

27. Friday November 14, 2003Delvin Defoe 27 Improved Timer Services  PERC VM associates a com.newmonics.pvm.PercThread object with each java.lang.Thread Provides access to additional time-related info. for threads Provides sleepUntil() and waitUntil() methods which can be used to implement non-drifting periodic and absolute timeouts  PERC VM allows developer to set tick period and the duration of each tick

28. Friday November 14, 2003Delvin Defoe 28 The VM Management API  In the case of embedded systems PERC makes it possible for software agents to self configure the embedded system  The GC pacing agent in PERC 4.1 is an example of one such agent It monitors trends in allocation rates, live memory retention, and object longevity Uses this info. to govern the rate at which GC is performed

29. Friday November 14, 2003Delvin Defoe 29 The VM Management API  The GC pacing agent in PERC 4.1 is an example of one such agent Objectives are to dedicate to GC exactly the amount of CPU time it needs and no more In overload situations, it raises alert signals rather than interfering with higher priority RT threads

30. Friday November 14, 2003Delvin Defoe 30 Relevant Application Domains  Network Elements  Automation  Commercial Telematics

31. Friday November 14, 2003Delvin Defoe 31 Limitations of PERC  Not recommended for hard real-time applications  Typical PERC-based deployments are about 3 times as large as and run at about 1/3 the speed of equivalent C programs

32. Friday November 14, 2003Delvin Defoe 32 Future Work  Extend PERC to include hard-real-time Java technologies  Add the capability to asynchronously interrupt a particular thread’s execution to the PERC run-time environment  Add the ability to establish time and space partitions for particular RT software components  Add an appropriate firm-real-time scheduling framework on top of firm-real-time Java technologies

33. Friday November 14, 2003Delvin Defoe 33 Questions?