From: Bill Bush [Bill.Bush@sun.com]
Sent: Monday, May 03, 2004 1:42 AM
To: kelvin@aonix.com
Subject: Re: Followup from last week's Open Group meetings


I haven't quite made it back from Brussels: note the time...

Here's the meld.  Most of the material's yours, especially toward the end when I was fading.  I tried to relate the notes to the specific headings in the document.

1. Throwing of Exceptions

  Clarification: This describes a simple default that requires no allocation.
     It does not preclude the use of exceptions that that allocate objects in
     immortal memory.
  Note: Java 1.5 and JSR 166 move items from thread group into thread
  Decided: There was support for preallocation of exceptions, though a
     preference was expressed to have one preallocated exception per thread.
     Further thought and discussion is required.

2. Threads and Interrupts

  Clarification: The focus of this section is first level interrupts, which
     can be handled either in Java or the native RTOS.  The goal of this
     proposal is to support those interrupts in Java, running on bare iron.
  Decided: Lots of heated discussion, no real conclusions.  Kelvin's (and
     Bill's) understanding: this is still open for further discussion.  As
     other issues regarding synchronization, analyzability, and so forth are
     decided, we will have a more solid foundation upon which to base
     discussions regarding implementation of first-level interrupts in Java.

3. Time-Bounded Execution

  Clarification: the main goal of this proposal is to enforce analysis.
  Notes: Determinining analyzability is platform independent.  Determining
    worst-case bounds is platform dependent (and will require annotations).
  Note: Non-blockability may be more important than analyzability.
  Decided: Need for further thought in the context of an API.
  Task: Kelvin will consider the needed API.
  Task: Bill will will investigate an annotation approach (perhaps looking at
    JDK 1.5 Meta Data and/or JML) (Concerns raised: do we want to force
    upgrade to JDK 1.5?  will the annotations be reflected in byte code?)

4. Locks and Synchronization

  Decided: Only priority ceiling will be supported; priority inheritance will
     not be.
  Note: A flaw in a static analyzer is equivalent to a flaw in the VM -- both
     result in erroneous execution.
  Specifically Decided:
  1. We will not use Lockable interface.  The presence of a synchronized
     method within a declared class implies Lockable.
  2. We agreed to restrict locking to this object only.  We will start by
     permitting only synchronized methods, not statements.  (Synchronized
     statements are just syntactic sugar.) If we find this too limiting in
     practice, then we will consider adding synchronized statements where the
     target object must be "this".
  3. and
  7. There will be no Mutex or semaphores in the safety-critical subset for
     now.  If we find this too limiting in actual practice, then we will
     consider adding semaphores and Mutex at a later time.
  4. and
  5. We will not use the PCP and Atomic interfaces.  Instead, all locking in
     the safety-critical Java subset will use PCP.  Atomic is more an aspect
     of analyzability, and that is to be treated separately.
  6. Andy Wellings suggested using the RTSJ MonitorControl and
     PriorityCeilingEmulation classes to specify celing priority, using "Max
     Priority" for any internal locks that don't otherwise specify the ceiling
     priority.  Kelvin expressed concern regarding the scalability of this
     approach.
       Suppose a mission-critical Java superset of the safety-critical
       standard supports the combination of PCP and priority inheritance.
       Will we desire syntactic markers to distinguish objects designed for
       use with PCP vs. PI? Also, can we simplify the MonitorControl API?
       For example: setMonitorControl()'s effects are per thread. And an
       object's monitor control, once set, will not change.
     Need for further thought and discussion.
  7. and
  8. There will be no wait/notify in the safety-critical subset.  The "proper"
     way to support notification in a safety-critical hard real-time system is
     to fire() an asynchronous event.  This eliminates the need for blocking
     behaviors, and simplifies the analysis of the real-time workload.
  9. The 1.0 standard for safety-critical java will not support
     multiprocessors.  We will try to establish conventions that will scale to
     multiprocessor implementations in a 1.x or 2.0 specification.

5. Dynamic Memory Management

  Decided: There was support for further investigation of the use of syntactic
     markers in Java source code to enable reliable (run-time exception free)
     allocation of Java objects on the run-time stack. A refinement of the
     proposed approach was requested. The refinement should:
     - Provide one syntactic marker to identfy the stack frame within which a
       stack-allocated object is to be allocated, and a different syntactic
       marker to identify variables that may refer to Java objects allocated
       on the stack of outer-nested contexts.
     - Make sure the syntactic conventions generalize to interfaces.  We need
       to be able to describe interfaces that allow references to
       stack-allocated objects, including this.
     - Generalize the support for stack allocation of objects that are to be
       returned from inner-nested method invocations multiple levels deep in
       the call chain.  (The proposal as distributed allows stack allocation
       for returned objects only one invocation level deep.)
     - Enable greater flexibility, so that inner-nested stack-allocated
       objects can reliably refer to outer-nested stack-allocated objects.
     - Provide sample programming excerpts, to let people digest how this is
       intended to work.
  Task: Kelvin will refine the proposal.

6. Initialization of Class Variables
7. Starting up a Safety-Critical Java Application
  Decided: There is support for the use of a "smart linker" to pre-initialize
     the load image.
   - However, special provisions must be made to support initialization
     expressions that depend on native code and/or may exhibit run-time side
     effects.  We need to address this in the next draft.
  Decided: There is general support for starting up the safety-critical
     real-time system with a main method.
   - The suggestion was to run the main method at max priority (28?) rather
     than at min priority (1).  This needs more discussion.
  Decided: The safety-critical Java run-time will shutdown under the same conditions
     specified for RTSJ shutdown.
  Decided: If a safety-critical Java thread terminates because of an uncaught
     run-time exception, a special event will be fired, allowing user code to
     perform appropriate remedial activities.

Note: The next draft of the document will be formatted with MIF-Doclet, with
   the intent to make the API description more browsable.