The RealTime Specification for Java

1
The Real-Time Specification for Java

• Lin Gu
• lingu_at_cs.virginia.edu

2
Outline

• Purpose
• Overview of an example application
• Design
• Discussion on the RTSJ design
• Conclusion

3
Purpose

• Make Java real-time
• What is real-time?
• John Stankovic "A real-time system is one in
  which the correctness of the computations not
  only depends upon the logical correctness of the
  computation but also upon the time at which the
  result is produced. If the timing constraints of
  the system are not met, system failure is said to
  have occurred."
• Hard/soft real-time
• RTSJ predictable execution

4
Purpose feasibility

• Why Java?
• Popularity
• Feasible?
• Prospective applications
• Critical web sites
• Banks, online stores, media sites
• Enterprise applications
• ERP, MRPII, groupware

5
Example -- overview

• A human-computer game server Chess server. A
  human being plays with the server online.
• Limited time to response (1 min).
• Whoever is unable to make a move within 1
  minute loses the game.
• Maximum of 120 minutes.
• Accordingly, the responsibilities of the server
  include
• Accept requests of new chess games
• Monitor and manage ongoing chess games
• When the opponent makes a move, compute the
  response in time

6
Example task description

• For this game server to meet the temporal
  requirements, two things are needed.
• 1. A method to formally specify the real-time
  requirements
• 2. A system that can guarantee to meet the
  real-time requirements
• In RTJ, the above two things corresponds to
• 1. Extended real-time classes (not Java
  compiler)
• 2. Real-time JVM

Specified by RTSJ
7
Sample code - scheduler

• public class ThinkExample
• public static void run()
• Object o
• PriorityParameters pp new
  PriorityParameters(10)
• AperiodicParameters ap new
  AperiodicParameters(new
• RelativeTime(5000L,0),new
  RelativeTime(5000L,0),null,null)
• try
• System.out.println(ThinkExample")
• PriorityScheduler ns new
  PriorityScheduler()
• Scheduler.setDefaultScheduler(ns)
• MemoryParameters memory new
  MemoryParameters(60000L,60000L)
• RealtimeThread think new
  RealtimeThread(pp,ap)
• boolean b ns.setIfFeasible(think,
  ap, memory)
• if (b) think.start()
• catch (Exception e)
• System.out.println("SchedulerSample
  exception")

Create the scheduler
Check feasibility
8
Sample code - memory

• public class ThinkMemoryExample implements
  Runnable
• public void run()
• ScopedMemory ma
• try
• ma new ScopedMemory (65536L)
• if (!(ma instanceof MemoryArea))
• throw new Exception("Return object is not
  instanceof MemoryArea")
• long size ma.size()
• if (size lt 0) throw new
  Exception("Memory size is less than 0")
• catch (Exception e) System.out.println(
  Example exception")
• try
• ma.enter(new Runnable()
• public void run()
• System.out.println(Thinking)
• )
• catch (Exception e) System.out.println(
  "enter(Runnable) failed")

Check the memory area
Run with the memory area
9
Example Thread activity and virtual machine
requirements
Play
Admission control
Short periodic task More important Periodic
Time constraint 50 sec Less important
Time tracking
Thinking
Time constraint 5 sec Most important
Hurry move

• The VM must be able to
• Perform feasibility calculation
• Execute the threads in a reasonable (timely)
  way
• Terminate a thread safely

10

• RTSJ exactly regulates those two things
  Real-time requirements specification, real-time
  Java virtual machine behavior
• Detail follows

11
Design Brief description of RTSJ

• One of the several efforts to make Java real-time
• NIST Specification, International J Consortium
  Specification (www.j-consortium.org), improved
  JVM (http//www.newmonics.com)
• Document still under development
• The Reference Implementation
• From TimeSys.com
• Other implementations IBM implemented all except
  Asynchrony features, Ajile (http//www.ajile.com)
  implemented part of the RTSJ, Simple RTJ by RTJ
  Computing

12
Design Methodology

• Basically, modify the existing system
• Identify problems
• Scheduling, memory, asynchronous events
• Clarify issues
• New objects, new properties of old objects
• Specify syntax and semantics
• Definitions of interfaces, classes, methods, and
  their semantics
• Must consider the diversity of real-time systems
• Must consider future extension of this
  specification
• Specify the syntax and semantics, but not
  implementations
• But, what would a reasonable implementation look
  like?

13
Design -- Requirements

• Requirements
• Real real-time (predictable execution)
• Compatibility
• Applicable to various Java platforms
• Able to run legacy programs
• Some Java features may be compromised (e.g.,
  WORA)
• Software engineering issues
• Flexibility (enough?)
• Quick implementation (no extension to Java
  language) a wise choice?

14
Design -- Identify

• Problems
• Scheduling
• Memory management
• Synchronization
• Typical real-time features that are not yet in
  Java

15
Design Clarify

• Solution
• Scheduling allow for new schedulers
• Memory management more types of memory
• Synchronization rules
• Typical real-time features that are not yet in
  Java add them
• Asynchronous Event Handling
• Asynchronous Transfer of Control
• Asynchronous Thread termination
• Physical Memory Access

16
Design Specify

• Scheduling
• The schedule must deal with execution eligibility
• A base scheduler (Priority scheduler) is provided
• Suppose we have fewer priority levels from OS
• More scheduler can be added
• Priority may be an over-simplified abstraction.
  Where is the real time in real-time?
• Suppose we want to add a new scheduler

17
Design Scheduling
feasibility test
Play
Admission control
Release parameters
Short periodic task More important Periodic
Time constraint 50 sec Less important
Time tracking
Thinking
Time constraint 5 sec Most important
Hurry move
Scheduling parameters
18
Design Specify

• Memory management
• Garbage collection (GC)
• No GC algorithms are good enough
• Priority order hard to be maintained in
  Synchronization
• One of the main motivations for expanding Javas
  memory management model is to eliminate GCs
  effect on real-time threads
• Different types of memories
• Scoped memory
• Physical memory
• Immortal memory
• Heap memory

19
Design memoryThinking algorithm

• Divide and conquer
• Use multi-thread to exploit as much computing
  capacity as possible
• Accumulate a Win/ Lose pattern library
• Use hashing access to the library
• Dynamic memory allocation

20
Design memorySample usage Internal
Thinking Main
Heap is not helpful Strong dynamic characteristics
Pattern lib
Thinking Original board
Thinking Move rook
Thinking Move bishop
Thinking Move pond
21
Design memory

• Scoped memory
• Reference constraints

22
Design memory

• Scoped memory
• Single parent rule
• Scope stack behavior

Violate the rule
MA3
MA2
MA2
MA1
MA4
Primordial scope
23
Design memorySample usage Internal
Thinking Main
Pattern lib
MA1
Thinking Original board
MA2
MA1
Thinking Move rook
Thinking Move bishop
Thinking Move pond
MA3
MA4
MA5
MA2
MA2
MA1
MA2
MA1
MA1
24
Design memory

• ImmortalMemory
• Life cycle is as long as the application
• Can we implement it as a special instance of
  ScopedMemory?

Thinking Main
ImmortalMemory
MA1
25
Design Synchronization

• Synchronization
• Maintaining appropriate behavior based on
  execution eligibility
• No unbounded priority inversion
• Priority inherence
• Priority ceiling
• Some rules
• Threads executes in the order of execution
  eligibility
• FIFO when eligibilities equal
• Yielding threads really yield

26
Design Specify

• Typical real-time features that are not yet in
  Java add them
• Physical Memory Access
• DMA, ports, byte-swapped
• Asynchronous Event Handling
• Asynchronous Transfer of Control
• Asynchronous Thread termination

27
Design Asynchrony

• Asynchronous event handling and transfer of
  control in execution
• Not all real-life events are predictable in time
  and frequency.
• Ability of real-time systems to react to them
  correctly requires reliable asynchrony techniques.

28
Design Asynchrony

• Conventional ways of achieving it in Java is by
  interrupts and exceptions.
• Can cause data structure corruption.
• RTSJ offers two extended approaches for real-time
  threads-
• Asynchronous Events (AEv).
• Asynchronously Interrupted Exceptions (AIE).

29
Design Asynchrony Class Hierarchy
Runnable
Object
Schedulable
AsyncEvent
AsyncEventHandler

• AsyncEventHandler behave like Thread (might be
  light-weighted)
• BoundAsynchronousHandler can be used for added
  timeliness by binding each handler to a dedicated
  thread.

BoundAsyncEventHandler
30
Design Asynchrony
Event2
Event1
Event3
Handler B
Handler A

• AsyncEventHander and AsyncEvent are
  independent to each other
• Many to many relationship.

31
Design Asynchrony

• Some change in the system environment needs
  immediate attention.
• Abandon current execution or take appropriate
  action.

32
Design Asynchrony
Object
Throwable
Exception
Interruptible
InterruptedException
AsynchronouslyInterruptedException
33
Design Asynchrony

• ATC is achieved by throwing a special exception
  AIE.
• RT threads and methods can choose to receive (or
  not to) AIE by including it in throws clause.
• The programmer can control the handling of the
  AIE. it is deferred if control is in synchronized
  block

34
Design Asynchrony Asynchronous Thread
Termination

• Using AEv and AIE together can achieve
  asynchronous termination of threads
• Allow threads to do cleanup

35
Design Asynchrony Chess server
Play
Interruptable
Thinking
Event1
Handler A
Event2
Time tracking
Event3
Handler B
Hurry move
Fire
36
Design Review

• What RTSJ has done
• Scheduling allow for new schedulers
• Memory management more types of memory
• Synchronization rules
• Typical real-time features that are not yet in
  Java add them
• Asynchronous Event Handling
• Asynchronous Transfer of Control
• Asynchronous Thread termination
• Physical Memory Access
• The next step is to implement them correctly and
  efficiently
• What would the performance look like?

37
Design Efficiency
From Ron. K. Cytron et al, Real-Time Java
38
Discussion on the design

• Expected performance
• OS Java VM Apps
• Will this be suitable for critical applications?
• Design of the specification
• Specify more, or specify less?
• In memory management Allow the programmer to
  query information characterizing the behavior of
  the garbage collection algorithm, and to some
  limited ability, alter the behavior of that
  algorithm. Hence, a GarbageCollector class and a
  getPreemptionLatency method are specified.
  (over/under specify?)
• Wait queue FIFO order when exec eligibilities
  equal (overspecify?)
• Are the principles accurately honored?
• Complete?
• Included all the main areas concerned with RT?
• No. Other areas of indeterminism exist, e.g.,
  environment variances.
• Included all the features described in itself?
• Approximately yes.
• But a designer still needs to fill the gap
  between the specification and a reasonably useful
  implementation.

39
Discussion on the design

• Lets predict some future extensions and verify
  whether they come to be true after the next
  version of RTSJ is released
• More concrete specifications on scheduling.
  Specifically, a reference scheduler may be
  provided, besides the base scheduler
• More strict characterization and control over the
  garbage collector
• As an industrial activity, interaction with other
  Java/Web/Middleware technology may be specified

40
Conclusion

• The RTSJ has accomplished most of the goals it
  specified
• The design choices are well-considered and
  prudent, but not necessarily correct
• Specification is just one aspect of promoting
  real-time Java technology. We will wait to see
  the final results

41
Thanks for your patience!