Reference-oriented language and high-integrity software

Reference-oriented language and high-integrity software

[Maciej Sobczak]

John Barnes in "Programming in Ada 2005", in the introductory section in 
the chapter devoted to access types, writes:

"Java is currently popular. It has pointers which are called references. 
In fact almost everything is declared using references although this is 
hidden from the user. This means that Java is inappropriate for high 
integrity applications."

What is interesting is the following implication which JB leaves without 
explanation:

references => no high integrity

It's also clear that the above statement applies not only to Java in 
particular, but to every other language that is similarly 
"reference-oriented".

My question is - where this implication comes from?

Taking into account that JB also wrote a book about SPARK, some 
reasoning can be found there and my understanding (simplified) is that 
reference-oriented language implies a heavy use of dynamic memory, which 
makes it impractical/impossible to perform any static analysis of memory 
consumption. Garbage collectors add their own factors to the problem.

Is the above a reasonable explanation? Is it the only one? What else 
makes the reference-oriented languages inappropriate for high-integrity 
software?

And last but not least, how does the JB's statement stand in front of 
things like RealTime Java or even HIJA (High-Integrity Java)?


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Reference-oriented language and high-integrity software

[Ludovic Brenta]

Maciej Sobczak <no.spam@no.spam.com> writes:
> Taking into account that JB also wrote a book about SPARK, some
> reasoning can be found there and my understanding (simplified) is that
> reference-oriented language implies a heavy use of dynamic memory,
> which makes it impractical/impossible to perform any static analysis
> of memory consumption. Garbage collectors add their own factors to the
> problem.
>
> Is the above a reasonable explanation? Is it the only one? What else
> makes the reference-oriented languages inappropriate for
> high-integrity software?

The other part of the explanation, AFAIU, is that a reference can go
wrong, i.e. point to deallocated memory, to unallocated memory, or to
the wrong piece of memory.  References also introduce aliasing,
i.e. two references can point to the same item.  All these make it
almost impossible to statically prove that no unintended side effects
ever occur in the program (correctness means: do what you're supposed
to do; safety means: do not do what you're not supposed to do.  It is
this latter part that matters to the present discussion).

-- 
Ludovic Brenta.

Re: Reference-oriented language and high-integrity software

[Maciej Sobczak]

Ludovic Brenta wrote:
> Maciej Sobczak <no.spam@no.spam.com> writes:
>> Taking into account that JB also wrote a book about SPARK, some
>> reasoning can be found there and my understanding (simplified) is that
>> reference-oriented language implies a heavy use of dynamic memory,
>> which makes it impractical/impossible to perform any static analysis
>> of memory consumption. Garbage collectors add their own factors to the
>> problem.
>>
>> Is the above a reasonable explanation? Is it the only one? What else
>> makes the reference-oriented languages inappropriate for
>> high-integrity software?
> 
> The other part of the explanation, AFAIU, is that a reference can go
> wrong, i.e. point to deallocated memory, to unallocated memory, or to
> the wrong piece of memory.

This can be rebutted on the basis that those languages ensure that 
nothing like this happens (no pointer arithmetic + garbage collector).

>  References also introduce aliasing,
> i.e. two references can point to the same item.  All these make it
> almost impossible to statically prove that no unintended side effects
> ever occur in the program

This makes sense in case of Java, but one could also argued that 
immutability of objects - a common feature in some reference-oriented 
languages - can make it less severe.

So - let's imagine a language, which is reference-oriented with all 
objects immutable. Apart from dynamic memory, is there any problem?

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Reference-oriented language and high-integrity software

[roderick.chapman]

The provision of _sound_ (i.e. no false negatives) and _fast_ aliasing
analysis
a key factor, even in the absence of dynamic memory and garbage
collection.

The soundness (and efficiency) of the information flow analyser
and the VC Generator (which is basically an implementation
of Hoare's assignment axiom) depend on this property.
 - Rod, SPARK Team

Re: Reference-oriented language and high-integrity software

[Georg Bauhaus]

roderick.chapman@googlemail.com wrote:
> The provision of _sound_ (i.e. no false negatives) and _fast_ aliasing
> analysis
> a key factor, even in the absence of dynamic memory and garbage
> collection.

By analogy then, a coffee seller telling us that coffee is
good for our health could have had an opportunity of being convincing.
Why not allude to the reasons for Java being inappropriate
right next to the claim? Other companies (including SofCheck
and Aonix I guess) might find this claim far too general.

I might have missed its context, my copy is too old to include
what sounds like Java bashing, but given this thread, I would
guess there isn't enough explicit context.



-- Georg 

Re: Reference-oriented language and high-integrity software

[Ludovic Brenta]

Maciej Sobczak <no.spam@no.spam.com> writes:
>> The other part of the explanation, AFAIU, is that a reference can go
>> wrong, i.e. point to deallocated memory, to unallocated memory, or to
>> the wrong piece of memory.
>
> This can be rebutted on the basis that those languages ensure that
> nothing like this happens (no pointer arithmetic + garbage collector).

And your rebuttal can be rebutted at the highest criticality levels
where you do not certify the source text, but the object code emitted
by the compiler.  In those contexts you do not even trust the
compiler.  References make the object code even more difficult to
certify.

>>  References also introduce aliasing, i.e. two references can point
>> to the same item.  All these make it almost impossible to
>> statically prove that no unintended side effects ever occur in the
>> program
>
> This makes sense in case of Java, but one could also argued that
> immutability of objects - a common feature in some reference-oriented
> languages - can make it less severe.

Yes, provided you trust the compiler - which you don't in
high-integrity software.

> So - let's imagine a language, which is reference-oriented with all
> objects immutable. Apart from dynamic memory, is there any problem?

Yes.  Tracing the object code to the source text, and certifying the
object code.  I'm not saying it's impossible to do; just that it's
unacceptably expensive to do.

-- 
Ludovic Brenta.

Re: Reference-oriented language and high-integrity software

[Georg Bauhaus]

Ludovic Brenta wrote:
> Maciej Sobczak <no.spam@no.spam.com> writes:

>> So - let's imagine a language, which is reference-oriented with all
>> objects immutable. Apart from dynamic memory, is there any problem?
> 
> Yes.  Tracing the object code to the source text, and certifying the
> object code.  I'm not saying it's impossible to do; just that it's
> unacceptably expensive to do.

On what premises?
I could argue that an index value, while being in
range of its subtype, points(!) to the wrong half of an array.
While this looks like an algorithmical issue, 
deterministic handling of preallocated storage can be an algorithmic
issue, too. What about placement new or storage pools?
How expensive is proving an algorithm that maps a finite number
of source text variables to a fixed size storage pool as a function
of <...experts insert here...>?

Re: Reference-oriented language and high-integrity software

[Peter Amey]

Maciej Sobczak wrote:

[snip]

> 
> And last but not least, how does the JB's statement stand in front of 
> things like RealTime Java or even HIJA (High-Integrity Java)?
> 

The answer to this one is, I think, a bit easier.  Neither RealTime Java 
nor HIJA can reasonably be described as Java.  The last time I looked, 
both required special compilers; were designed to produce native machine 
code not an interpreted J code; allocated objects on the stack rather 
than heap; and had no garbage collection.  The restrictions mean that 
you cannot use any of the standard libraries and don't get platform 
portable code; the two primary attraction of Java in the first place. 
What you do have is two new languages that just happen to have a 
Java-like syntax.  The modifications required to give these new 
languages their real-time and high integrity credentials are precisely 
aligned with John Barnes's objections to them.

regards

Peter

Re: Reference-oriented language and high-integrity software

[Martin Krischik]

Peter Amey schrieb:
> 
> 
> Maciej Sobczak wrote:
> 
> [snip]
> 
>>
>> And last but not least, how does the JB's statement stand in front of 
>> things like RealTime Java or even HIJA (High-Integrity Java)?
>>
> 
> The answer to this one is, I think, a bit easier.  Neither RealTime Java 
> nor HIJA can reasonably be described as Java.  The last time I looked, 
> both required special compilers; were designed to produce native machine 
> code not an interpreted J code; allocated objects on the stack rather 
> than heap; and had no garbage collection.  The restrictions mean that 
> you cannot use any of the standard libraries and don't get platform 
> portable code; the two primary attraction of Java in the first place. 
> What you do have is two new languages that just happen to have a 
> Java-like syntax.  The modifications required to give these new 
> languages their real-time and high integrity credentials are precisely 
> aligned with John Barnes's objections to them.

So the only advantage they have is the use of a Marketing-Buzz-Word - or 
better the combination of two of them ("Java" + XXX).

Martin

Re: Reference-oriented language and high-integrity software

[Dr. Adrian Wrigley]

On Fri, 03 Nov 2006 12:37:35 +0000, Peter Amey wrote:

> Maciej Sobczak wrote:
> 
> [snip]
>> 
>> And last but not least, how does the JB's statement stand in front of 
>> things like RealTime Java or even HIJA (High-Integrity Java)
> 
> The answer to this one is, I think, a bit easier.  Neither RealTime Java 
> nor HIJA can reasonably be described as Java.  The last time I looked, 
> both required special compilers; were designed to produce native machine 
> code not an interpreted J code; allocated objects on the stack rather 
> than heap; and had no garbage collection.  The restrictions mean that 
> you cannot use any of the standard libraries and don't get platform 
> portable code; the two primary attraction of Java in the first place. 
> What you do have is two new languages that just happen to have a 
> Java-like syntax.  The modifications required to give these new 
> languages their real-time and high integrity credentials are precisely 
> aligned with John Barnes's objections to them.

So the advantage is that you can attempt use existing programmers
for writing high integrity/real-time software.  And the code
produced can even be executed with standard compilers/runtimes,
albeit without the benefits of the HI/RT environment.
And of course, all the IDEs, code analysis tools can be used.
Sounds rather useful.

The skeptics (Martin) are saying the only benefit is better buzz-words.
But then SPARK Ada is based on the same philosophy (restricted
language, compiler, run-time to achieve tougher HI/RT goals).
--
Adrian

Re: Reference-oriented language and high-integrity software

[Simon Wright]

"Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> writes:

> So the advantage is that you can attempt use existing programmers
> for writing high integrity/real-time software.  And the code
> produced can even be executed with standard compilers/runtimes,
> albeit without the benefits of the HI/RT environment.
> And of course, all the IDEs, code analysis tools can be used.
> Sounds rather useful.

I would have expected the cost of teaching a random programmer to
create good SPARK annotations would be quite a bit greater than the
cost of teaching a random Java programmer to write Ada (to the
equivalent level of competence, assuming that's acceptable of course).

We are developing a large-ish VxWorks application, but most of the
work is done on the host (Windows, eeew). With GNAT, you get the host
compiler as part of the cross-development bundle ...

Re: Reference-oriented language and high-integrity software

[Jean-Pierre Rosen]

Dr. Adrian Wrigley a �crit :
> So the advantage is that you can attempt use existing programmers
> for writing high integrity/real-time software.  
> 
Experience shows that people over-estimate the time to learn a new 
language, and under-estimate the time to train people to the constraints 
of writing high integrity/real-time software. Better take an experienced 
real-time programmer and teach him Ada, than the other way round!

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Reference-oriented language and high-integrity software

[Martin Krischik]

Dr. Adrian Wrigley schrieb:

> The skeptics (Martin) are saying the only benefit is better buzz-words.
> But then SPARK Ada is based on the same philosophy (restricted
> language, compiler, run-time to achieve tougher HI/RT goals).

I was comparing HIJA with (SPARK-)Ada.

But we should not underestimate better buzz-words as that is all what 
Management and Recruitment understands.

Martin