Mission-Critical Design: Ada.Unchecked_Deallocation vs Garbage Collection

Mission-Critical Design: Ada.Unchecked_Deallocation vs Garbage Collection

[NiGHTS]

In mission-critical design applications, do they favor garbage collectors or the unchecked deallocation?

The dangling pointer thing is definitely a problem I've had to deal with in complex C programs that I have debugged. But I can also see how having an unpredictable pool of memory hanging over the program could be a problem as well. I suppose this question is highly dependant on the application and target.

What are your thoughts on this? When is it better to use garbage collection and when is it better to use classic new & delete memory management when a life may be on the line?

Re: Mission-Critical Design: Ada.Unchecked_Deallocation vs Garbage Collection

[Jeffrey Carter]

On 07/17/2014 11:17 PM, NiGHTS wrote:
> In mission-critical design applications, do they favor garbage collectors or
> the unchecked deallocation?
>
> What are your thoughts on this? When is it better to use garbage collection
> and when is it better to use classic new & delete memory management when a
> life may be on the line?

Typically, safety-critical systems don't allow dynamic allocation and deallocation.

-- 
Jeff Carter
"You a big nose have it."
Never Give a Sucker an Even Break
107

Re: Mission-Critical Design: Ada.Unchecked_Deallocation vs Garbage Collection

[J-P. Rosen]

Le 18/07/2014 08:25, Jeffrey Carter a écrit :
> On 07/17/2014 11:17 PM, NiGHTS wrote:
>> What are your thoughts on this? When is it better to use garbage 
>> collection and when is it better to use classic new & delete memory
>> management when a life may be on the line?
> 
> Typically, safety-critical systems don't allow dynamic allocation
> and deallocation.
> 
... especially in Ada, where MUCH can be accomplished without resorting
to pointers, unlike many other languages.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Mission-Critical Design: Ada.Unchecked_Deallocation vs Garbage Collection

[Pascal Obry]

Le vendredi 18 juillet 2014 à 09:51 +0200, J-P. Rosen a écrit : 
> ... especially in Ada, where MUCH can be accomplished without resorting
> to pointers, unlike many other languages.

Right, I've heard that some projects still allow allocation of a buffer
during elaboration in a pool and then use only this space as heap. All
memory allocation is prohibited after.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Mission-Critical Design: Ada.Unchecked_Deallocation vs Garbage Collection

[Dennis Lee Bieber]

On Thu, 17 Jul 2014 23:17:48 -0700 (PDT), NiGHTS <nights@unku.us> declaimed
the following:

>In mission-critical design applications, do they favor garbage collectors or the unchecked deallocation?
>
	Based upon the examples I've seen at work (flight management systems):
NEITHER...

	Any dynamic memory gets allocated during the initialization step (based
on some configuration "file" to identify how much of each component to
create), and once that completes the only "dynamic" memory is the stack
(and not even the secondary stack used in some operations -- like run-time
string concatenation; no: put("string " & integer'image(val) & " more"); )

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Mission-Critical Design: Ada.Unchecked_Deallocation vs Garbage Collection

[Robert A Duff]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> On Thu, 17 Jul 2014 23:17:48 -0700 (PDT), NiGHTS <nights@unku.us> declaimed
> the following:
>
>>In mission-critical design applications, do they favor garbage collectors or the unchecked deallocation?
>>
> 	Based upon the examples I've seen at work (flight management systems):
> NEITHER...
>
> 	Any dynamic memory gets allocated during the initialization step (based
> on some configuration "file" to identify how much of each component to
> create), and once that completes the only "dynamic" memory is the stack
> (and not even the secondary stack used in some operations -- like run-time
> string concatenation; no: put("string " & integer'image(val) & " more"); )

That particular example can be done without using the secondary stack in
the latest version of GNAT.  All the temps are allocated on the primary
stack, with compile-time-known size.  The length of X&Y is equal to the
sum of the lengths of X and Y.  The maximum length of the 'Image result is 11.

Take a look at the output of -gnatD if you want to see how that works.

- Bob

Re: Mission-Critical Design: Ada.Unchecked_Deallocation vs Garbage Collection

[Dennis Lee Bieber]

On Wed, 23 Jul 2014 18:07:10 -0400, Robert A Duff
<bobduff@shell01.TheWorld.com> declaimed the following:

>That particular example can be done without using the secondary stack in
>the latest version of GNAT.  All the temps are allocated on the primary

	Ah... But now we are in that unknown category: has the latest version
of GNAT passed the certification tests needed to be approved for use on our
application... (I was just CC'd on an email at work in which it was
discovered that the VMS cross-compiler had been patched in 1992 [obviously
an Ada-83 compliant system], used for 14 years, yet the official document
for the compiler version to be cited in all documentation was prior to
that... Yes, we are using a 14-year-old cross compiler on an even older OS
-- because that is a certified development system... Just changing from
WinXP to Win7 [on another development system] requires heavy time&money
investment to certify that the binaries [to run on neither of those OSs]
have not changed!)
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Mission-Critical Design: Ada.Unchecked_Deallocation vs Garbage Collection

[Simon Wright]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> heavy time&money investment to certify that the binaries [...] have
> not changed

I was approached by an ex-colleague to help him understand why builds of
the same source code with the same compiler (GNAT 3.16a1, Windows x
VxWorks) didn't always produce the same executable. I couldn't (not at a
distance, anyway).

That's the sort of circumstance in which one really regrets not keeping
the support contract up!