Sun Java™ Real-Time System
(Java RTS) 2.2 Update 1 is Sun's implementation of the Real-Time
Specification for Java (RTSJ).
Each implementation of the RTSJ is required to provide documentation
for several behaviors.
This document describes Java RTS 2.2 Update 1 behavior, as indicated
by the "Required Documentation" section of the RTSJ.
If the feasibility testing algorithm is not the default,
document the feasibility testing algorithm.
Sun Java Real-Time System provides no feasibility testing algorithm
other than the default one.
If schedulers other than the base priority scheduler are available to
applications, document the behavior of the scheduler and its interaction with
each other scheduler as detailed in the Scheduling chapter. Document the list
of classes that constitute schedulable objects for the scheduler unless that
list is the same as the list of schedulable objects for the base scheduler.
If there are restrictions on use of the scheduler from a non-heap context,
document those restrictions.
Sun Java Real-Time System provides no scheduler other than the default
base scheduler.
A schedulable object that is preempted by a higher-priority schedulable object is placed in the queue for its active priority, at a position determined by the implementation. If the preempted schedulable object is not placed at the front of the appropriate queue the implementation must document the algorithm used for such placement. Placement at the front of the queue may be required in a future version of this specification.
In Sun Java Real-Time System, a schedulable object that is preempted by a higher-priority schedulable object is placed at the front of the queue for its active priority.
If the implementation supports cost enforcement, then the implementation is required to document the granularity at which the current CPU consumption is updated.
Sun Java Real-Time System does not support cost enforcement.
The memory mapping implemented by any physical memory type filter must be documented unless it is a simple sequential mapping of contiguous bytes.
Sun Java Real-Time System provides a proprietary interface to implement new memory mappers.
It is documented in the Javadoc™ of the
com.sun.rtsjx package.
The implementation must fully document the behavior of any subclasses of GarbageCollector.
Sun Java Real-Time System includes a new real-time garbage collector.
It comes with a new GarbageCollector class documented in
com.sun.rtsjx.FullyConcurrentGarbageCollector.
An implementation that provides any MonitorControl subclasses not detailed in this specification must document their effects, particularly with respect to priority inversion control and which (if any) schedulers fail to support the new policy.
Sun Java Real-Time System provides no other MonitorControl subclass.
If on losing "boosted" priority due to a priority inversion avoidance algorithm, the schedulable object is not placed at the front of its new queue, the implementation must document the queuing behavior.
Sun Java Real-Time System provides its own priority boosting mechanism, explicitly calling the operating system to change the priorities when needed. Whenever the priorities are changed, the threads go to the end of their new priority queue.
For any available scheduler other than the base scheduler an implementation must document how, if at all, the semantics of synchronization differ from the rules defined for the default PriorityInheritance monitor control policy. It must supply documentation for the behavior of the new scheduler with priority inheritance (and, if it is supported, priority ceiling emulation protocol) equivalent to the semantics for the base priority scheduler found in the Synchronization chapter. If there are restrictions on use of the scheduler from a no-heap context, the documentation must detail the effect of these restrictions for each RTSJ API.
Sun Java Real-Time System provides no scheduler other than the default base scheduler.
The worst-case response interval between firing an AsyncEvent because of a bound happening to releasing an associated AsyncEventHandler (assuming no higher-priority schedulable objects are runnable) must be documented for some reference architecture.
In Sun Java Real-Time System, assuming there is a single no-heap AsyncEventHandler attached to the event,
the response interval is in the tens of microseconds. Using processor sets on a 2.3Ghz biprocessor AMD machine,
the worst case measured interval was less than 45 microseconds on Solaris™ 10 Operating System update 4.
The interval between firing an AsynchronouslyInterruptedException at an ATC-enabled thread and first delivery of that exception (assuming no higher-priority schedulable objects are runnable) must be documented for some reference architecture.
In Sun Java Real-Time System, the interval depends on what the thread is doing. The important point is to know how much code the interrupted thread can continue to execute before being interrupted.
For an interpreted method, the worst case is the time required to execute one bytecode.
For a compiled method the thread checks for interruption upon method return (but only for non-inlined methods), entry into the runtime, and on backward branches in loops.
So the time taken to detect interruption is dependent on the code that the thread is executing, but typically short.
In addition, if the thread is executing native code, then the interruption will not be noticed until the native method returns (native code is not asynchronously interruptible).
The first two delays (interpretation of a bytecode and compiled-code checks) are negligible when compared to the third delay, as it is user and application dependent.
Users must measure the execution time of the native method they use in the sections they want to interrupt if they need a precise worst-case number.
If cost enforcement is supported, and the implementation assigns the cost of running finalizers for objects in scoped memory to any schedulable object other than the one that caused the scope's reference count to drop to zero by leaving the scope, the rules for assigning the cost shall be documented.
Sun Java Real-Time System does not support cost enforcement.
If cost enforcement is supported, and enforcement (blocked-by-cost-overrun) can be delayed beyond the enforcement time granularity, the maximum such delay shall be documented.
Sun Java Real-Time System does not support cost enforcement.
If the implementation of RealtimeSecurity is more restrictive than the required implementation, or has run-time configuration options, those features shall be documented.
The RealtimeSecurity manager in Sun Java Real-Time System is no more restrictive than the required implementation.
For each supported clock, the documentation must specify whether the resolution is settable, and if it is settable the documentation must indicate the supported values.
Sun Java Real-Time System provides no clock other than the required real-time clock, and it is not settable.
If an implementation includes any clocks other than the required real-time clock, their documentation must indicate in what contexts those clocks can be used. If they cannot be used in no-heap context, the documentation must detail the consequences of passing the clock, or a time that uses the clock to a no-heap schedulable object.
Sun Java Real-Time System provides no clock other than the required real-time clock.
