1 / 33

Doing Firm-Real-Time With J2SE APIs

Doing Firm-Real-Time With J2SE APIs. By Kelvin Nilsen, CTO, NewMonics. Delvin Defoe Center for Distributed Object Computing Department of Computer Science and Engineering Washington University. November 14, 2003. Firm real-time vs Soft real-time. Soft real-time “Qué será será”

charles-bailey
Download Presentation

Doing Firm-Real-Time With J2SE APIs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Firm real-time vs Soft real-time • Soft real-time • “Qué será será” • Whatever will be, will be

  3. Firm real-time vs Soft real-time • Firm real-time • Disciplined development in which software engineers carefully analyze • Deadlines • Resource requirements • schedulability

  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. 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. 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. 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. 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. 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. PERC Virtual Machine features • Allows each implementation to define basis for RT development • Number of priorities • Synchronization semantics • Wait queue ordering • Library compatibility

  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. 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. Implementation Choices and Semantic Guarantees • Real-Time garbage Collection • Threading Behavior and Priority Inheritance • Improved Timer Services • The VM Management API

  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. 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. Incremental Copying garbage Collection From-space A B C To-space C’ B’ A’ Reserved New Relocated Objects B and C are relocated so their valid copies are B’ and C’

  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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Relevant Application Domains • Network Elements • Automation • Commercial Telematics

  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. 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. Questions?

More Related