Section XX - Terms and Concepts
 

Real-time Concepts

Real-time Computing has two aspects: ‘operating in real-time’ and real-time resource management. A system (at any level of abstraction -- e.g., application, computer system, operating system, Java platform, etc.) operates in real-time to the degree that it satisfies the system's time constraints acceptably -- i.e., with acceptable optimality and predictability. To that end, resource management is real-time to the degree that it explicitly takes those time constraints into account. [Abstracted from Jensen]

Timeliness can be defined by three aspects: (1) any time constraints (e.g., deadlines) on individual activities (an activity is a portion of a thread's locus of execution); (2) the collective timeliness optimization criterion used for scheduling threads to meet their activity’s time constraints (e.g., meet all hard deadlines, minimize the number of missed deadlines according to their relative importance, minimizise mean tardiness, etc.), (3) the trade-off between the collective timeliness optimality and the predictability of that collective timeliness optimality value (e.g., mean tardiness or number of missed deadlines may be higher but their variance is lower, or vice versa). [Abstracted from Jensen]

Predictability is the degree to which something can be known a' priori. It implies the degree to which the future execution (system and application) context of that something can be predicted. Determinism and maximum entropy are the end-points on the scale of predictability, and coefficient of variation is an example of a predictability metric. [Abstracted from Jensen]

Hard DeadlineA hard deadline is an activity time constraint which requires that the activity complete by the deadline time in order to be considered timely; completion after the deadline is considered untimely (i.e., there is no utility in completing the activity). [Abstracted from Jensen]

Hard real-time Computing is the fulfillment of the timeliness property that: 1) the time constraints of interest are all hard deadlines; 2) the collective timeliness optimization criterion is to always meet all hard deadlines (optimality and predictability are both maximal). [Abstracted from Jensen]

A soft time constraint is one which is not hard -- i.e., an arbitrary function relating the utility of completing the activity to its completion time. [Abstracted from Jensen]

Atomic: Refers to an operation that is never interrupted or left in an incomplete state under any circumstances. [Javasoft]

Component: "Black box" components are sufficiently characterized by their specification, and are delivered in byte-code form. For real time systems, "sufficiently characterized" includes timing information and perhaps the rate of garbage production. For embedded systems, the resource footprint is also an issue.

Garbage collection: Process that automatically identifies dynamically allocated objects that are no longer reachable and reclaims the space occupied by the objects. Garbage collection consists of both garbage detection and garbage reclamation.

Incremental Garbage collection:

An Interpreter is a module that alternately decodes and executes every statement in some body of code. The Java interpreter decodes and executes Java bytecode. [Javasoft]

Process: a virtual address space containing one or more threads. [Javasoft]

Real-time component:

Real-time garbage collection:

A Runtime system is considered the software environment in which programs compiled for the JVM can run. The runtime system includes all the code necessary to load Java programs, dynamically link native methods, manage memory, handle exceptions, and an implementation of the JVM, which may be a Java interpreter. [Javasoft]

The Sandbox comprises a number of cooperating system components, ranging from security managers that execute as part of the application, to security measures designed into the JVM and the language itself. The sandbox ensures that an untrusted, and possibly malicious, application can not gain access to system resources. [Javasoft]

Thread: A schedulable entity that contends for a resource and is scheduled to acquire it. [Abstracted from Jensen]

The Virtual machine is an abstract specification for a computing device that can be implemented in different ways, in software or hardware. … The Java Virtual Machine consists of a bytecode instruction set, a set of registers, a stack, a garbage-collected heap, and an area for storing methods. [Javasoft]

[Javasoft] Sun Microsystems provides an online glossary of Java related terms. See http://www. Javasoft.com/docs/glossary.print.htm).

[Jensen] Doug Jensen, Mitre Corp., provides an excellent source of explanatory material on real-time concepts at: http://www.realtime-os.com/rt-java_glossary/transit/rt-java_glossary.htm

TM: Java and Java-based marks are trademarks of Sun Microsystems, Inc. in the United States and other countries.
 
 

Section XX - Java^(tm) Traits

The Requirements WG considers these Java Traits to provide a basis for the real-time requirements. (consensus – agree)

• Java’s higher level of abstraction allows for increased programmer productivity (although recognizing that the tradeoff is runtime efficiency).
• Java is relatively easier to master than C++.
• Java is relatively secure by keeping software components (including the VM itself) protected from one another.
• Java supports dynamic loading of new classes.
• Java is highly dynamic; supporting lots of object/thread creation at run time.
• Java is designed to support component integration and reuse.
• The Java technologies have been developed with careful consideration, erring on the conservative side using concepts and techniques that have been scrutinized by the community.
• The Java language and platforms support application portability.
• The Java technologies support distributed applications.
• Java provides well-defined execution semantics.

Section XX - Guiding Principles

1. The design of RTJ may involve compromises that improve ease of use at the cost of less than optimal efficiency or performance. (consensus –agree)

2. RTJ should support the creation of software with useful lifetimes that span multiple decades, maybe even centuries. (consensus – agree)

3. RTJ requirements are intended both to be pragmatic, by taking into account current real-time practice, as well as to provide a roadmap or direction to advance the state of the art.

Section XX - Goals and Derived Requirements

EDITOR’S NOTES:

1. Many of these requirements are written in terms of providing functionality, capabilities to application programmers. The WG should consider the underlying (and sometime hidden) ‘requirements’ that would be necessary to provide these capabilities. Additionally, the WG should consider using these as ‘Criteria to Evaluate’.
 

Derived Requirements:

DR 2.2 RTJ should support both the creation of small, simple systems, and large complex systems (possibly using different "profiles"). (consensus – agree)

DR 2.3 Standard subsets of RTJ and RTJVM specification should be created as necessary to support improved efficiency and/or reliability for particular specialized domains (consensus –agree) ED NOTE: The WG needs to define these domains. Possible candidates: ard real-time safety critical software, distributed systems, embedded systems. The WG needs to decide how to slice the pie.

Goal 3: Subject to resource availability and performance characteristics, it should be possible to write RTJ programs and components that are fully portable regardless of the underlying platform. (consensus – agree)

Derived Requirements:

DR 3.2 RTJ should abstract operating system and hardware dependencies. (consensus – agree)

DR 3.3 RTJ must support standard Java semantics. (consensus – agree)

DR 3.4 The RTJ technologies should maximize the use of non-RTJ technologies (e.g., development tools and libraries). (consensus – agree)

GOAL 4: RTJ should support workloads comprised of the combination of real-time tasks and non-real-time tasks. (consensus –agree)

Derived Requirements:

DR 4.1 Traditional Java software must run as non-real-time tasks. (consensus –agree)

DR 4.2 Facilities must be provided  to allow sharing of information between non-real-time and real-time tasks. (consensus –agree)

DR 4.3 The sharing protocols must provide the real-time programmer with the ability to avoid unpredictable blocking delays. (consensus –agree)

DR 4.4 The relationships between RTJ threads with the other three possible types of threads (non-real-time Java, non-Java real-time, and non-Java non-real-time) need to be formally defined. (consensus –agree) ED NOTE: Thread relationship paragraphs and model will be inserted here.

GOAL 7: RTJ should allow real-time application developers to write real-time constraints into their software. (consensus with serious reservations regarding the ramifications of these clauses.

Derived Requirements

DR 7.1 RTJ should provide application developers with the option of using conservative or aggressive resource allocation. (consensus – open)

DR 7.2 The same RTJVM should support combined workloads in which some activities budget aggressively and other conservatively. (consensus – open)

GOAL 8: Real-time Java should allow resource reservations and should enforce resource budgets. The following resources should be budgeted: CPU time, memory and memory allocation rate. (consensus – agree) ED NOTE: definition for memory allocation rate

GOAL 9:  RTJ should support the use of components as "black boxes"; including on the same thread. (consensus - open)

DR 9. 1: RTJ should support dynamic loading and integration of negotiating components. (consensus - agree)

GOAL 10: RTJ must provide real-time garbage collection when garbage collection is necessary. GC implementation ‘information’ must be visible to the RTJ application. (consensus –agree) ED NOTE: 1. definitions for RT GC, 2. Specify what constitutes GC implementation ‘information’.

Goal 13: RTJ should be implementable on operating systems that support real-time behavior. (consensus - agree)
 

Section XX - Resource Management (RM) Requirements

Example resources include:

• CPU resources raising issues of scheduling, preemption, fairness, time slicing;
• Exclusive access to shared data using synchronized block/method
• Access to restricted (user-defined) resources using wait/notify
• Network routines using RMI

The issues that these requirements address: ED NOTE: This section must be detailed.

• Deadlock avoidance
• Priority inversion
• Budgeting in Advance
• Static availability
• Global vs. local knowledge
• Deadline vs. priority
• Sytem knowledge vs. application knowledge
• Finalizers: how to ensure timeliness and correctness

Utility of Resource Management:

The following capabilities should be supplied or be implementable using the functionality delineated in the specification:

• dead-line based scheduler on top of (or perhaps within) RTJVM. (consensus –agree)
• time-sliced scheduler or periodic scheduler on top (or perhaps within), (optionally make time-slicing a required option.) (consensus –agree)
• resource accounting (especially CPU accounting.) (consensus –agree)
• The ability to determine maximum defferal of event due to primitives that block event. (In what units?) (consensus –open)

ED NOTE: Do the requirements below support these capabilities?
 

RM DR1: The RTJ API must be well-defined with guarantees on all language features. (consensus –agree)

RM DR1 is based on Goal 3: RTJ programs and components should be fully portable regardless of the underlying platform.
   

RM DR 2: Ability to enforce, with notification, event handling and accounting, space/time limits, in a scoped manner, from the outside; on "standard" Java features too. (consensus – agree)

RM DR2 is based on GOAL 9: RTJ should support the use of components as "black boxes"; including on the same thread. (consensus –open)
 
RM DR3: In a real-time context, existing Java features shall "work right" including ‘synchronized’ (bounded priority inversion) and ‘wait/notify’ (priority queuing). (consensus – agree)
Discussion: Any thread created in "scope" of user-defined policy manager is under control of that policy.  Pre-existing thread class priorities might be mapped to "real-time" priorities.

RM DR3 is based on GOAL 9: RTJ should support the use of components as "black boxes"; including on the same thread.
 
 

RM DR 4: RTJ must:

• At least support strict priority-based scheduling, queuing and lock contention. This should apply to existing language features too. (consensus – agree)
• At least support some kind of priority "boosting" (either priority inheritance or priority ceilings). This should apply to existing language features too. (consensus – agree)
• Support dynamic priority changes. (consensus – agree)
• Support ability to propogate a local priority and changes to remote servers (at some level of spec.?). Not just in support of RMI but also in support of user-written communication mechanisms. (consensus – open)
• Support ability to defer asynchronous suspension or disruption when manipulating a data structure.
• Ability to build deadline-based scheduler on top.
• Ability to query to find out the underlying resource availability (non-Java) and handle asynchronous changes to it.

RM DR4 is based on GOAL 8: RTJ should allow resource reservations and should enforce resource budgets. The following resources should be budgeted: CPU time, memory and memory allocation rate. (consensus – agree).

OPEN ISSUES:

1. What to do with ‘schedulability analysis’? Requires more discussion. (Roadmap requirement)

Section XX - Requirements for Memory Management (MM)

Utility of Memory Management

The following capabilities should be implementable using the functionality delineated in the specification:

• The ability to analyze code to determine memory consumption. (e.g., How much garbage is created and how much ‘non-garbage’ is created.) (consensus – open) ED NOTE: Do the requirements below support this capability?
• The ability to specify rate ‘hints’ for GC that would be paced according to the rate that memory is allocated. (consensus – open) ED NOTE: (1) Do we all know what is meant by ‘hints’? (2) Do the requirement below support this capability?
• The ability to partition/budget memory between components (e.g., Component A get memory regardless of what component B wants.) (consensus – open) ED NOTE: (1) Is plain old ‘components’ appropriate here? (2) Do the requirements below support this capability?

MM DR1: Language and libraries are clearly understood in terms of memory usage. (consensus – agree) ED NOTE: This requirement must be further refined to be useful.

MM DR1 is based on Goal 3: RTJ programs and components should be fully portable regardless of the underlying platform.
 

MMDR2: RTJ defines ‘garbage’. (consensus – agree) ED NOTE: Need definition of what consitutes garbage.

MMDR2 is based on Goal 10: RTJ must provide real-time garbage collection when garbage collection is necessary.  GC implementation 'information' must be visible to the RTJ application.
 

MMDR3: RTJ should provide ‘hint handling’ information regarding the GC, (e.g., accurate vs. conservative ? Does it defragment?). (consensus – open) ED NOTE: Paragraphs defiining the specific information to be inserted here.

MMDR3 is based on Goal 10: RTJ must provide real-time garbage collection when garbage collection is necessary.  GC implementation 'information' must be visible to the RTJ application.
 

MMDR4: RTJ must not restrict nor specify the garbage collection technique; rather it should be capable of supporting all appropriate techniques for RT GC. (consensus – agree)

MMDR4 is based on Goal 10: RTJ must provide real-time garbage collection when garbage collection is necessary.  GC implementation 'information' must be visible to the RTJ application.
 

MMDR5: The GC must make forward progress at some rate. The rate must be ‘queryable’ and configurable. (consensus – agree) ED NOTE: Paragraph further defining ‘forward progess’ (i.e., the ‘incremental discussion’ to be inserted here.

MMDR5 is based on Goal 10: RTJ must provide real-time garbage collection when garbage collection is necessary.  GC implementation 'information' must be visible to the RTJ application.
 

MMDR6: RTJ shall provide support for a guaranteed allocation rate. (consensus – agree)

MMDR6 is based on Goal 8: RTJ should allow resource reservations and should enforce resource budgets.  The following resources should be budgeted: CPU time, memory, and memory allocation rate.
 

MMDR7: RTJ must/should not require bounds on when an object is finalized or reclaimed. (consensus – agree)

MMDR7 is based on Goal ? (ED NOTE: Don't know)

MMDR8: Within RTJ the mutator overhead must be bounded if GC is in process. (consensus – agree)

MMDR8 is based on Goal 10: RTJ must provide real-time garbage collection when garbage collection is necessary.  GC implementation 'information' must be visible to the RTJ application.
 

MMDR9 is based on Goal 8: RTJ should allow resource reservations and should enforce resource budgets.  The following resources should be budgeted: CPU time, memory and memory allocation rate.
 
 

1. Finalizers (timeliness and correctness)
2. Stack-based allocation. Automatic or explicit?
3. Reference count GC.
4. Definition and use of the term ‘incremental’ for GC.

Converting hardware interrupts to synchronous events