From: Kelvin Nilsen [kelvin@aonix.com]
Sent: Wednesday, August 04, 2004 1:19 PM
To: kelvin@aonix.com; ogrtesf-scjava-spec-develop@opengroup.org
Subject: RE: Here are notes on evolution of the SCSJ from the Boston
Open Group Meetings


There were two other topics discussed, which I forgot to put into the 
notes I just distributed:

 11. We talked about using a generalization of the Real-Time Data 
     Access API in place of (or possibly to supplement) the IOPort 
     hierarchy that's in the current draft specification.  Aicas 
     is going to send current API documents so that we can explore 
     this further.

 12. It was considered important for us to establish the relevance of 
     SCSJ to mission-critical development.  Aonix pointed out that over 
     75% of our Raven product sales are used for mission-critical rather 
     than safety-critical development.  There are many mission-critical 
     projects that need the same hard real-time determinism, reliability, 
     high performance, and small footprint that is required by many safety-
     critical developers, even though these mission-critical developers 
     don't need the artifacts for safety certification.  Other participants 
     requested that Aonix provide a proposed API that can be used to 
     reliably and efficiently integrate SCSJ components with other mission-
     critical components running on a traditional Java VM (such as PERC or 
     HotSpot).  We will distribute a proposal for this API soon.  It was 
     the consensus of the group that we should propose to standardize this 
     API in a separate JSR from the SCSJ.


> -----Original Message-----
> From: Kelvin Nilsen [mailto:kelvin@aonix.com]
> Sent: Wednesday, August 04, 2004 12:56 PM
> To: ogrtesf-scjava-spec-develop@opengroup.org
> Subject: Here are notes on evolution of the SCSJ from the Boston Open 
> Group Meetings
>
>
>
> We reviewed the "Draft Safety Critical Java Standard", dated June 21, 
> 2004.
>
>  1. It was pointed out that the use of exception handling in 
> safety-critical code is somewhat contraversial.  According to certain 
> style guidelines (established for more traditional languages like 
> Ada), exception handling is considered an unacceptable source of 
> asynchrony.  But other safety-critical projects have been known to 
> embrace exception handling as a "good thing".
>

Ben Brosgol provided the following clarification:

The issue here isn't really asynchrony, since problems arise even with 
purely synchronous exceptions: certifying the run-time libraries that 
implement exception handling, and demonstrating coverage analysis etc 
for code that might raise exceptions.



> The suggestion made was that we should look for ways to abstract 
> exception handling in general behind some sort of a statically 
> enforced framework abstraction.  The idea is that a developer should 
> have the ability to specify that he wants a certain component or 
> collection of components to be protected from any exception handling.  
> In this circumstance, the developer should be able to count on some 
> sort of static analysis tool to enforce that the code will not throw 
> exceptions and will not need to catch exceptions.
>
>  2. The request was made to organize this document (or perhaps a 
> collection of documents) to distinguish between the specification 
> itself, rationale for the various design tradeoffs represented by the 
> specification, and general recommendations for directed at developers 
> who are writing application software to run on the SCSJ platform.  It 
> was strongly encouraged that we not lose track of the many thought 
> processes that have contributed to the creation of the specification.  
> But also, we should make it easy for readers to digest the 
> specification in its most current form without requiring them to fully 
> assimilate all of the history associated with it.  In this context, we 
> should try to distinguish, for example, the content of section 2 
> (which is more of a philosophy) from section 4 (which details many of 
> the rules that characterize a "legal" SCSJ program).
>
>  3. A request was made to consider standardizing on the CLDC lbrares 
> rather than the draft API that was distributed previously.  I have 
> since taken a look at the CLDC libraries.  Here are my comments on 
> that approach:
>
>   a) There are many parts of the CLDC spec that I think would be 
> appropriate for inclusion in the SCSJ platform description.  For 
> example, I would be very comfortable specifying that we will use their 
> byte-code verification techniques.  However, it appears to me that the 
> CLDC API is much larger than would be appropriate for safety-critical 
> development in general, so I would prefer not to adopt that API 
> wholesale.
>
>   b) The CLDC 1.1 specification makes clear that this API is designed 
> for application programming and NOT for system programming.  That is 
> almost exactly the opposite of the SCSJ's target audience.
>
>   c) Because of the certification requirements associated with DO-178B 
> level A, we should expect each line of code to cost hundreds or 
> thousands of dollars (to develop and certify).  For this reason, we 
> need to think very carefully about each library component added to the 
> standard SCSJ platform.
> The CLDC 1.1 targeted memory footprint is 192 KBytes.  While this is 
> much smaller than traditional Java, it is much larger than the typical 
> practice for safety-critical level A deployments, where it is much 
> more likely for the level A component to be less than 32 Kbytes of machine code.
>
>   d) There are certain components of the SCSJ that are inherently 
> non-compatible with the requirements of SCSJ.  For example:
>
>     I believe we have agreed that there will be no dynamic class 
> loading or initialization in SCSJ v. 1.0.
>
>     This also means we don't want to assume a file system, a network 
> stack, or "Connector" abstractions.
>
>     Since we don't have garbage collection, we also don't want to deal 
> with things like weak pointers.
>
>     Multi-level security is probably not relevant.  All software 
> within a given SCSJ application is generally presumed to run at the 
> same security level.
>
>     I believe we agreed there would be no java.io (and thus no 
> javax.microedition.io).  Supporting io in a standard and portable way 
> (that generalizes to mission-critical systems, timeouts, and other 
> asynchronous transfer of control) is very difficult.  It represents a 
> "research project"
> that could easily consume many engineering months from multiple 
> contributors.
>
>     We do not want to instantiate any java.lang.Thread, so our version 
> of this class must be abstract with a private constructor.
>
>
>   e) There are other components that, if we decide to include them, we 
> must do much more work to carefully document their required behavior 
> within the SCSJ environment.  For example:
>
>     Calendar, Date, and TimeZone: how do these notions of time 
> dovetail into the hard real-time clocks?  do the methods of these 
> classes allocate memory?
> do the methods of these classes create links between previously 
> allocated objects?
>
>      Internationalization: I'd prefer to not bother with this in the SCSJ.
> If we include it, we must very carefully describe the memory 
> allocation and access behaviors of any internationalization libraries.
>
>      Collections, while useful, are especially troublesome with 
> respect to dynamic memory management.  Are these allowed to modify 
> relationships/references between previously allocated objects?  Will 
> this cause them to throw run-time exceptions under certain 
> circumstances?  What circumstances would lead to run-time exceptions?  
> Will these libraries allocate new memory?  When can that memory be 
> reclaimed?  How will that memory be reclaimed?  In general, I believe 
> a collections library designed for hard real-time uses will probably 
> have different APIs than the standard java.util collections library.
>
>
>  4. Some dissatisfaction was expressed (mainly by Aicas) regarding the 
> proposed static annotation approaches.  In particular, the convention 
> to have different modes of analysis that are keyed by static constants 
> rather than dynamic parameter values bothered Aicas.  Aicas also felt 
> that the combined use of meta-data annotations and assertion statements was clumsy.
> They would have preferred to have all static annotations expressed in 
> the same meta-language notation.  They suggested the possible use of 
> JML as the alternative notation.  But others in attendance felt that 
> JML was too extreme a solution, because JML is only one of many 
> possible annotation languages, all of which are still in the research 
> phase of development, and none of which have yet become standardized, 
> whereas Java assertions and meta-data annotations have already been 
> adopted by the JCP for inclusion in JDK 5.  We requested that Aicas 
> discuss their analysis modes issues with Andy Wellings, who was the 
> originator of that concept (insofar as the SCSJ is concerned).  We 
> also requested that Aicas come back with some sort of proposal for how 
> they would improve upon the current draft specification for static 
> annotations.
>
>  5. In discussing the implementation of meta-data annotations in JDK 
> 1.5, we discovered (to our chagrin) that javac does not preserve 
> meta-data annotations associated with local variables in the class 
> files.  This will require a change to the specification as currently 
> drafted.  My proposed revision is as follows:
>
>    Any local variable that is assigned a copy of a @Stackable instance 
> field (anywhere within the body of the method) is considered to be a 
> @Stackable variable itself (throughout the body of the method).  This 
> variable's contents can only be copied to other @Stackable variables.
>
>    Any local variable that is assigned the result of a new operation 
> for which the corresponding constructor is declared with the 
> @StackableThis attribute is considered to be a @Stackable variable iff 
> this variable's contents is only assigned to other @Stackable 
> variables.  If the variable is considered @Stackable, the allocated 
> object will be stack allocated.
> Otherwise, it will be allocated within the immortal memory region.
>
>    As a notational convention, programmers would be encouraged to 
> annotate their local variables with the @Stackable annotation, but 
> this would not be enforced for the time being.  Perhaps some future 
> version of Java will fix this shortcoming, so that we can enforce the 
> behavior with an appropriate byte-code verifier.
>
>  6. We agreed to change the names of the meta-data annotations.
> Rather that
> @Stackable, @StackableThis, @StackableResult, we will use: @Scoped, 
> @ScopedThis, @CallerAllocated.  We will also introduced a new annotation:
> @ScopedPure which means all reference parameters, including this, are 
> scoped.  So you could say, for example:
>
>     public @ScopedPure Object method(Object key, Object data);
>
> instead of:
>
>     public @ScopedThis Object method(@Scoped Object key, @Scoped 
> Object data);
>
> @ScopedPure does not necessarily mean @CallerAllocated.  That 
> annotation must be provided separately, if it is desired.
>
>  7. There was a bit of unease associated with the use of the 
> @AllowCheckedStackableLinks (aka @AllowCheckedScopedLinks).  As 
> described in the draft documents, a programmer is by default 
> prohibited from being allowed to link stack-allocated objects to each 
> other within any context that would require a run-time check to be 
> performed, and the possibility of a run-time exception being thrown.  
> Note that within the constructor of a and newly allocated object (not 
> @CallerAllocated), we do not need to check assignments to its instance 
> fields because this object is necessarily in the most shallow position 
> of the run-time stack.  As drafted, the spec says that a programmer 
> would be allowed to build more sophisticated data structures out of 
> stack-allocated objects only if the programmer annotates his method 
> with the @AllowCheckedStackableLinks notation.  Aicas preferred to 
> forbid this entirely, saying programmers should not be allowed to 
> write any code that might cause a run-time check and exception.  My 
> personal feeling is that there are many situations (and I presented a 
> sample program to motivate this notation) under which programmers can 
> demonstrate to their satisfaction that run-time exceptions will not be 
> thrown.  However, some of the arguments used by programmers to 
> demonstrate absence of run-time exceptions are beyond the capability 
> of automatic static property theorem provers to confidently assert.  
> Thus, the annotation is required to make the program "legal".
> Personally, I'd like to see some prospective users of these 
> technologies weigh in.  Which approach do they prefer?
>
>   [Aside: It appears that Aicas is considering implementation of 
> scoped objects using heap memory allocation with their Jamaica VM and 
> real-time garbage collection.  In that environment, it is "unnatural" 
> to throw run-time exceptions because no checking is performed on heap 
> allocated objects.  An alternative approach is the one suggested by 
> Andy Wellings in his recent report from the HIJA kickoff meeting.  If 
> nested LT dynamic scopes are used to implement the scoped allocations 
> (as well they could be), then it would be most natural to have a 
> run-time check associated with each assignment to a stack-allocated 
> object's reference fields.]
>
>  8.  The suggestion was made that we could "caller allocate" checked 
> exceptions at the point of each proposed catch statement.  This is a 
> little tricky, and needs further investigation.  Some of the issues 
> that come immediately to mind are:
>
>    a) What if the throw statement throws a subclass of the type 
> declared by the catch statement?  This subclass may require more 
> memory than the superclass.
>
>    b) What if the catch statement rethrows the exception or allows 
> references to the exception to escape the current scope?  Then it is 
> not appropriate to stack allocate the exception in this scope.
>
>    c) If we become dependent on this "trick" for those situations 
> where it might work, what solution do we use in the many situations 
> for which it does not work?  Maybe we should instead adopt a more 
> general solution (such as preallocated shared instances of exceptions) 
> that works reliably in all situations.
>
>  9. The PCP class highlights the "impedance mismatch" between the 
> RTSJ, in which almost all real-time properties are dealt with 
> dynamically, as they would typically be treated by an RTOS, and the 
> SCSJ, in which as many real-time properties as possible are 
> constrained statically by the language compiler, so that important 
> static properties can be proven at compile time by static analysis and 
> verification tools.  Requiring programmers to satisfy the demands of 
> both communities makes development a little awkward.  The suggestion 
> was made that we might want to introduce a subclass of PCP to be used 
> whenever programmers want to enforce static determination of priority 
> ceilings and static proofs that nested PCP locking will not result in 
> PriorityCeilingViolation exceptions.  Then we could presumably relax 
> some of the static analysis requirements on the use of PCP itself.  
> This needs further exploration.
>
>  10. The draft spec says the initial startup thread runs at priority 
> 28.  It should have stated that the initial startup thread runs at the 
> highest non-interrupt priority level.  This will be corrected in the 
> next release of the document.
>
>
>
> (I'm sure everyone will be pleased to know that I've got a new laptop 
> with a keyboard that actually works!)
>
>
> ----
> Kelvin Nilsen, Ph.D.
> Chief Technology Officer
> Aonix North America
> 877 S. Alvernon Way, Ste. 100
> Tucson, AZ  85711
>   520-323-9011, ext. 118 (direct), 520-991-6727 (cell), 520-323-9014 
> (fax)
>