Ammo-zilla

Ammo-zilla

[Stanley R. Allen]

If anyone out there is struggling with their organization to retain
(or introduce) Ada as an alternative to C++, consider this:

    http://www.mozilla.org/hacking/portable-cpp.html

Imagine what Ada's detractors would be saying if writing portable
Ada code was as restrictive as writing C++ code is these days!

Other aspects of the Mozilla project may provide interesting
insights concerning the impact of language choice on project
success; for example, it would be interesting if some study
could determine the percentage of Mozilla bugs related to the
those characteristics of C/C++ infamous for bug-o-genesis. 

-- 
Stanley Allen
mailto:s_allen@hso.link.com

Re: Ammo-zilla

[Aidan Skinner]

On Sat, 23 Oct 1999 14:42:39 -0500, Stanley R. Allen
<s_allen@hso.link.com> wrote: 

>could determine the percentage of Mozilla bugs related to the
>those characteristics of C/C++ infamous for bug-o-genesis. 

Having had a quick glance over teh Mozilla bug list, ISTM that there's
a lot of memory leaks in it, which Ada is a lot better for.

- Aidan (except for code I right when really tired, which for some
  reason has a tendancy to leak like a sponge)

-- 
"I say we just bury him and eat dessert"
http://www.skinner.demon.co.uk/aidan/

Re: Ammo-zilla

[Robert Dewar]

In article <slrn8156pm.pl.aidan@skinner.demon.co.uk>,
  aidan@skinner.demon.co.uk wrote:
> that there's
> a lot of memory leaks in it, which Ada is a lot better for.


Now that's an interesting comment, because to me C++ and Ada
are identical in this particular department, can you explain
why you think Ada is better wrt memory leaks?


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ammo-zilla

[David Botton]

> Now that's an interesting comment, because to me C++ and Ada
> are identical in this particular department, can you explain
> why you think Ada is better wrt memory leaks?

As a result of the excellent design of Ada, I use far more static 
allocation then dynamic resulting in less chance of memory leaks. Of 
course once you start playing with the heap its all about personal 
programmer discipline.

David Botton

Re: Ammo-zilla

[Charles Hixson]

I am continually attracted to Ada, however:
The Ada approach to memory management reminds me of the PL/1 approach,
only simplified a bit.  I suppose that you can say that it's better than
C++, but that's *REALLY* faint praise.  There are a lot of details that
I don't fully understand, but this is one of Ada's weaker aspects.  The
second is the syntax used in "object" declaration.  Very clumsy.

Now I *do* understand that the reason for this approach is (partially
the date of design but also) to allow statically linked programs to be
small enough for embedded systems, etc.  And it is indeed necessary to
enable this.  But the cost of a unified design of this nature is that,
e.g., garbage collection is eliminated from the language.  (The syntax
is mainly due to early design.)  I feel relativly certain that if the
language were to be designed today that many things would have been done
differently.

David Botton wrote:

> > Now that's an interesting comment, because to me C++ and Ada
> > are identical in this particular department, can you explain
> > why you think Ada is better wrt memory leaks?
>
> As a result of the excellent design of Ada, I use far more static
> allocation then dynamic resulting in less chance of memory leaks. Of
> course once you start playing with the heap its all about personal
> programmer discipline.
>
> David Botton

Re: Ammo-zilla

[Matthew Heaney]

In article <38189268.43EB150F@mail.earthlink.net> , Charles Hixson 
<charleshixsn@mail.earthlink.net>  wrote:

> The second is the syntax used in "object" declaration.  Very clumsy.

Huh?

procedure Do_Something is
  I : Integer;
begin

I is an object.  What's so "clumsy" about its declaration?


> But the cost of a unified design of this nature is that, e.g., garbage
> collection is eliminated from the language.  (The syntax is mainly due to
> early design.)

Huh?  Ada was carefully designed to allow an implementation to provide
garbage collection.

Garbage collection is not provided[1] by Ada compiler vendors because
users have decided that they don't want it, not because the RM has
"eliminated" it.

[1] Excepting those implementations of the JVM, which *do* provide
garbage collection.


--
If we let the Creationists have their way, we may as well go whole hog.
Let us reintroduce the flat-earth theory, the chemistry of the four
elements, and mediaeval astrology.  For these outworn doctrines have
just as much claim to rival current scientific views as Creationism does
to challenge evolutionary biology.

Abusing Science: The Case Against Creationism
Philip Kitcher

Re: Ammo-zilla

[mitch]

In article <3818bec3_4@news1.prserv.net>, "Matthew says...
 
>> The second is the syntax used in "object" declaration.  Very clumsy.
>

>Huh?
>
>procedure Do_Something is
>  I : Integer;
>begin
>
>I is an object.  What's so "clumsy" about its declaration?
>
 
I think he is talking about tagged object. 

any way, I did program in Java for more than 2 years now. And I still
prefer the functional type of programming. I prefer to think of DATA first,
then operations on DATA next. 

I like to see the structure of the data itself as the main focuse, 
then the operations on that data. So languages like Ada and pascal 
seem more natural to me, where ADT's and packages fit more
with this style of thinking.

In Java, where objects are everywhere, and where you have objects 
inside objects inside objects inside objects, for large complex 
application, I find that managing and maintaining this is harder 
than in a language where the Data itself is the center. 

I still believe in the old saying that a program = Data+Algorithms.
or may be I am just getting too old :)

mitch 

Re: Ammo-zilla

[Matthew Heaney]

In article <7vaie8$2p1@drn.newsguy.com> , mitch@nospam.com  wrote:

> In article <3818bec3_4@news1.prserv.net>, "Matthew says...
>
>>> The second is the syntax used in "object" declaration.  Very clumsy.
>>
>
>>Huh?
>>
>>procedure Do_Something is
>>  I : Integer;
>>begin
>>
>>I is an object.  What's so "clumsy" about its declaration?
>>
>
> I think he is talking about tagged object.


  package P is

    type T is tagged private;
    <ops>
  end P;


  with P;  use P;
  procedure Do_Something is

    O : T;
  begin


T is a tagged type.  O is a tagged object.  What's the problem?


--
The theory of evolution is quite rightly called the greatest unifying
theory in biology.  The diversity of organisms, similarities and
differences between kinds of organisms, patterns of distribution and
behavior, adaptation and interaction, all this was merely a bewildering
chaos of facts until given meaning by the evolutionary theory.

Populations, Species, and Evolution
Ernst Mayr

Re: Ammo-zilla

[Tucker Taft]

Charles Hixson wrote:
> 
> I am continually attracted to Ada, however:
> The Ada approach to memory management reminds me of the PL/1 approach,
> only simplified a bit.  I suppose that you can say that it's better than
> C++, but that's *REALLY* faint praise.  There are a lot of details that
> I don't fully understand, but this is one of Ada's weaker aspects.  The
> second is the syntax used in "object" declaration.  Very clumsy.
> 
> Now I *do* understand that the reason for this approach is (partially
> the date of design but also) to allow statically linked programs to be
> small enough for embedded systems, etc.  And it is indeed necessary to
> enable this.  But the cost of a unified design of this nature is that,
> e.g., garbage collection is eliminated from the language.  (The syntax
> is mainly due to early design.)  I feel relativly certain that if the
> language were to be designed today that many things would have been done
> differently.

That's an interesting question.  I have on occasion since we finalized
the Ada 95 design thought about how I might design a language if I
could really start from scratch.  After a huge amount of horsing around,
I end up surprisingly close to where Ada 95 is now.  For example,
you mention the "clumsy" syntax associated with object declarations.
It is interesting to note that Haskell, one of the more elegant
functional programming languages out there, has essentially the
identical object approach as Ada 95, as does CLOS, common lisp object 
system. 

If you are used to the notion of an abstract data type, defined by a
type and a set of operations, and then you decide you want to support
extensibility of abstract data types, then you end up at something
very much like Ada 95, Haskell, or CLOS, with the 
"operation(operand, operand, ...)" or "operand <operator> operand"
or "object := operation(operand, operand,...)" syntax familiar from
theoretical mathematics and logic.  If you instead focus on
updating objects as the primary operations of interest, then you end up with
the <obj>.<operation> syntax.  In some ways, the Ada 95 syntax is
more sympathetic with the "value-oriented" (i.e. functional) way
of thinking than the "object-oriented" (i.e. side-effecting) way
of thinking.  The net effect, in any case, is that you can more easily
write in a "functional" style in Ada 95 where there is less use of
heap-resident read/write objects, and more use of values (rather than 
objects) of an abstract type being passed around, assigned, declared, etc. 

One interesting side note -- because Ada is a multi-tasking language,
the objects that are designed to retain read/write global state need some kind
of synchronization/protection.  For such objects (tasks and protected
objects), the object.operation(...) syntax is intentionally chosen, because
there is clearly a special role played by the "target" task or
protected object.  By contrast, for value-oriented operations like
set union, the symmetrical syntax of "union(set1, set2)" seems far
more intuitive than "set1.union(set2)", and the symmetrical syntax
is used for such operations in Ada. 

Speaking from experience of using Java, although the object.operation(...)
syntax can be convenient sometimes, surprisingly often I find conceptual
operations for which there are at least two conceptual operands, generally
of different types/classes, that are just as appropriate (or perhaps,
just as inappropriate) as the "prefix" operand in the object.operation(...)
syntax.  Generally, I suppose the distinction is between operations whose
primary role is to update some operand (in which case, it makes sense
to be identified specially), versus those operations that create some
output given two or more inputs, in which case it is arbitrary which
of the inputs ends up being put "out front" in the object.operation(...)
syntax.

As usual in all such discussions, your mileage may vary...

> David Botton wrote:
> 
> > > Now that's an interesting comment, because to me C++ and Ada
> > > are identical in this particular department, can you explain
> > > why you think Ada is better wrt memory leaks?
> >
> > As a result of the excellent design of Ada, I use far more static
> > allocation then dynamic resulting in less chance of memory leaks. Of
> > course once you start playing with the heap its all about personal
> > programmer discipline.
> >
> > David Botton

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Ammo-zilla

[Brian Rogoff]

On Thu, 28 Oct 1999, Tucker Taft wrote:
> Charles Hixson wrote:
> > 
> > I am continually attracted to Ada, however:
> > The Ada approach to memory management reminds me of the PL/1 approach,
> > only simplified a bit.  I suppose that you can say that it's better than
> > C++, but that's *REALLY* faint praise.  There are a lot of details that
> > I don't fully understand, but this is one of Ada's weaker aspects.  The
> > second is the syntax used in "object" declaration.  Very clumsy.
> > 
> > Now I *do* understand that the reason for this approach is (partially
> > the date of design but also) to allow statically linked programs to be
> > small enough for embedded systems, etc.  And it is indeed necessary to
> > enable this.  But the cost of a unified design of this nature is that,
> > e.g., garbage collection is eliminated from the language.  (The syntax
> > is mainly due to early design.)  I feel relativly certain that if the
> > language were to be designed today that many things would have been done
> > differently.
> 
> That's an interesting question.  I have on occasion since we finalized
> the Ada 95 design thought about how I might design a language if I
> could really start from scratch.  After a huge amount of horsing around,
> I end up surprisingly close to where Ada 95 is now.  For example,
> you mention the "clumsy" syntax associated with object declarations.
> It is interesting to note that Haskell, one of the more elegant
> functional programming languages out there, has essentially the
> identical object approach as Ada 95, as does CLOS, common lisp object 
> system. 

Haskell doesn't support OOP, in particular, it doesn't support dynamic 
dispatch so I don't think the comaprison is appropriate. Besides Lisp 
derivatives like CLOS and Dylan, the only functional programming language 
I know of which supports OOP is Objective Caml. OCaml uses the
distinguished receiver notation with "#" instead of ".".

I prefer the Ada notation, but I don't think the notational choice is as 
big a deal as some people make it out to be. I think if you could design
Ada from scratch you could use some more tokens like "[", "]", "{", and 
"}" instead of using parens for everything.

> If you are used to the notion of an abstract data type, defined by a
> type and a set of operations, and then you decide you want to support
> extensibility of abstract data types, then you end up at something
> very much like Ada 95, Haskell, or CLOS, with the 
> "operation(operand, operand, ...)" or "operand <operator> operand"
> or "object := operation(operand, operand,...)" syntax familiar from
> theoretical mathematics and logic.  If you instead focus on
> updating objects as the primary operations of interest, then you end up with
> the <obj>.<operation> syntax.  In some ways, the Ada 95 syntax is
> more sympathetic with the "value-oriented" (i.e. functional) way
> of thinking than the "object-oriented" (i.e. side-effecting) way
> of thinking.  The net effect, in any case, is that you can more easily
> write in a "functional" style in Ada 95 where there is less use of
> heap-resident read/write objects, and more use of values (rather than 
> objects) of an abstract type being passed around, assigned, declared, etc. 

Agreed. Since there is this contingent of functional programming devotees
in the Ada community, perhaps we'll see anonymous access to subprogram 
types, downward closures via access to subprogram, and other FP tools in 
the next version of Ada :-). 

-- Brian

Re: Ammo-zilla

[Robert Dewar]

In article
<Pine.BSF.4.10.9910311929570.12649-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> Haskell doesn't support OOP, in particular, it doesn't support
> dynamic dispatch so I don't think the comaprison is
> appropriate.


I find it continually confusing that people confuse a
programming paradigm (OOP) with some features in the language
that are useful for supporting this paradigm.

The point is of course that dynamic dispatching, type extension,
and inheritance, are all generally useful features. They can
be used for many things, only one of which is object oriented
programming. In fact in my experience, the more common use is
simply in making more flexible, reusable abstract data types
(many people think they are doing OOP when they do this!)

The dot notation and distinguished receiver notions are indeed
useful when you are doing OOP, but they get in the way of many
other uses of these features (in particular, modeling a
dispatching addition operator in this way makes little sense,
but there are lots of other answers).

So the argument about notation is almost always off center,
since on the one hand you have people who are concerned with
one very specific use of the features, and on the other hand,
you have people who see these features as much more general.

The distinction between:

  Obj.Method1 (X);

and

  Method1 (Obj, X);

is basically a rather small syntactic distinction, and there is
no issue of loss of expressive power. But if we go entirely to
the first notation, then we will lose a lot of generality,
generality that will be sorely missed by those of us who use
these features all the time in non-OOP contexts.

Note in particular that object oriented programming is all about
objects which have state.

But the basic capabilities (type extension, inheritance, dynamic
dispatching) are equally (perhaps more) applicable to pure value
oriented programming using conventional abstract data types. In
this context, the notion of a distinguished receiver is a
distraction if you are just talking about computing an output
value from input values.

Of course this point has been made many times before, and by
many different people, in many different ways, but I have seen
nothing stated that would begin to contradict the most useful
viewpoint, as expressed above.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ammo-zilla

[Brian Rogoff]

On Mon, 1 Nov 1999, Robert Dewar wrote:
> In article
> <Pine.BSF.4.10.9910311929570.12649-100000@shell5.ba.best.com>,
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> > Haskell doesn't support OOP, in particular, it doesn't support
> > dynamic dispatch so I don't think the comaprison is
> > appropriate.
> 
> 
> I find it continually confusing that people confuse a
> programming paradigm (OOP) with some features in the language
> that are useful for supporting this paradigm.

I'm not confusing anything. Since OOP, and Ada's function call notation 
are under discussion, comparisons with non-OOP languages are weak. I 
could just as well argue that since one can do OOP in C (and indeed, many 
people do!) that C's function call notation for OOP validates the Ada 
choice. That argument is more powerful too, since the number of C users 
outnumbers those of Haskell (and CLOS, and Ada combined :-) and stateful 
programming is more convenient in C than Haskell.

No reasonable Haskell user will claim that the Haskell type system  
supports OOP well. Perhaps with existential types...

-- Brian

Re: Ammo-zilla

[Robert Dewar]

In article
<Pine.BSF.4.10.9911011726330.5772-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:

> > I find it continually confusing that people confuse a
> > programming paradigm (OOP) with some features in the
language
> > that are useful for supporting this paradigm.
>
> I'm not confusing anything. Since OOP, and Ada's function call
> notation are under discussion, comparisons with non-OOP
> languages are weak.

To me there is no such thing as an OOP language, since OOP is
not a language feature, it is a programming paradigm, which can
of course be used in any language.

One can certainly discuss the ease and convenience of using this
paradigm in a particular language.

And one can bias the language syntax to make this particular
paradigm particularly convenient.

But I think that is a mistake, since the fundamental notions
of inheritance, dynamic dispatching, and type extension are
far more powerful, and cover a much wider range of programming
styles and approaches than simply OOP.

If you specialize the syntax too much for OOP, then you will
make these useful features much less available for other uses,
and that is what has happened in several other languages. I
particularly dislike the style of C++ programming where you
write conventional abstract data types, with a functional and
procedural style, and are then forced into the inappropriate
dot notation for calling functions which have nothing whatsoever
to do with objects or "distinguished receivers".

Maybe my experience is atypical, but I see this kind of C++
program FAR more frequently than I see real object oriented
programs (that does not surprise me, the notion of ADT's is
to me far more general than the notion of objects).

(of course the programmers of these C++ programs are actually
under the illusion they are doing object oriented programming,
because they are using the word class, and everyone knows that
C++ is an "object oriented programming language".)



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ammo-zilla

[Brian Rogoff]

On Tue, 2 Nov 1999, Robert Dewar wrote:
> In article
> <Pine.BSF.4.10.9911011726330.5772-100000@shell5.ba.best.com>,
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> 
> > > I find it continually confusing that people confuse a
> > > programming paradigm (OOP) with some features in the
> language
> > > that are useful for supporting this paradigm.
> >
> > I'm not confusing anything. Since OOP, and Ada's function call
> > notation are under discussion, comparisons with non-OOP
> > languages are weak.
> 
> To me there is no such thing as an OOP language, since OOP is
> not a language feature, it is a programming paradigm, which can
> of course be used in any language.

The fact that you think there is no such thing as an OOP language 
doesn't stop the many programmers from using the term. I think 
most people wouldn't put Haskell in that category. Similarly, there 
may be no such thing as a "functional programming language", but most 
people would use some criteria (presence of first class functions, 
lexical scope, ...) to determine membership in this class.

This is way off topic, and actually, I agree with almost everything you
wrote anyways...

-- Brian

Re: Ammo-zilla

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> I find it continually confusing that people confuse a
> programming paradigm (OOP) with some features in the language
> that are useful for supporting this paradigm.

I've seen so many conflicting definitions of "OOP" (and Object Oriented
Anything Else), that I think the phrase is pretty useless at this point
for conveying information other than marketting hype.  ;-)

Perhaps you should explain which definition you're using in this
thread.

- Bob

Re: Ammo-zilla

[Laurent Guerby]

Charles Hixson <charleshixsn@mail.earthlink.net> writes:
> [...] But the cost of a unified design of this nature is that,
> e.g., garbage collection is eliminated from the language. [...]

Quite the contrary, garbage collection is allowed (but not mandated)
by the language (see section 13.11.3 of the Ada 95 RM), and it's of
course available for Ada compilers targetting the JVM.

--LG

Re: Ammo-zilla

[David Starner]

On 28 Oct 1999 22:42:52 +0200, Laurent Guerby <guerby@acm.org> wrote:
>Charles Hixson <charleshixsn@mail.earthlink.net> writes:
>> [...] But the cost of a unified design of this nature is that,
>> e.g., garbage collection is eliminated from the language. [...]
>
>Quite the contrary, garbage collection is allowed (but not mandated)
>by the language (see section 13.11.3 of the Ada 95 RM), and it's of
>course available for Ada compilers targetting the JVM.

Under the "as if" rule, C allows garbage collection, and I've got a
C compiler that compiles targetting the JVM. 

If garbage collection is not mandated, however, then it can't be relied on in 
Ada code that might run under systems that don't garbage collect - i.e. 
portable Ada code can't use it. Hence either you deallocate any memory 
yourself, or suffer garbage leaks while running under a non-garbage 
collecting system.

--
David Starner - dstarner98@aasaa.ofe.org

Re: Ammo-zilla

[Larry Kilgallen]

In article <7vadsp$8q61@news.cis.okstate.edu>, dvdeug@x8b4e53cd. (David Starner) writes:

> If garbage collection is not mandated, however, then it can't be relied on 
> in Ada code that might run under systems that don't garbage collect - i.e. 
> portable Ada code can't use it. Hence either you deallocate any memory 
> yourself, or suffer garbage leaks while running under a non-garbage 
> collecting system.

Vendors are free to implement garbage collection and will do so
to the extent that the market demands.

They have done so, including the vendor of "free" compilers.

Larry Kilgallen

Re: Ammo-zilla

[David Starner]

On Fri, 29 Oct 1999 02:19:10 GMT, Larry Kilgallen <kilgallen@eisner.decus.org> 
wrote:
>In article <7vadsp$8q61@news.cis.okstate.edu>, dvdeug@x8b4e53cd. 
>(David Starner) writes:
>
>> If garbage collection is not mandated, however, then it can't be relied on 
>> in Ada code that might run under systems that don't garbage collect - i.e. 
>> portable Ada code can't use it. Hence either you deallocate any memory 
>> yourself, or suffer garbage leaks while running under a non-garbage 
>> collecting system.
>
>Vendors are free to implement garbage collection and will do so
>to the extent that the market demands.
>
>They have done so, including the vendor of "free" compilers.

I said nothing about vendors. As long as there are otherwise-reasonable
Ada compilers that don't garbage collect, good Ada programs must assume
they're running on that system. 

I once pointed out that integer'base could be an infinite precision
integer type. (Robert Dewar said yes, but it wasn't something that
was going to get added to GNAT.) Let's say that it was added to GNAT.
Good portable Ada code still couldn't depend on having 70 digit+ 
integer types. GC is the same - as long as most systems don't support it,
(and I'm not familiar with any major ones that don't run on the JVM that 
do), you can't depend on it. And as long as you can't depend on it, GC's
main advantage - saving the programer trouble worring about memory - is
useless. 

As a side question: Ada 95's designers must have been familiar with Modula 3's
support of garbage collection while letting real time stuff keep track of
its own memory. What stopped them from adopting something like that for
Ada 95?

--
David Starner - dstarner98@aasaa.ofe.org

Re: Ammo-zilla

[David Botton]

Perhaps they knew not every one wants GC in their programs, compilers, and
environments :-)
I often wished when writing Java code that I could force the JVM to clean up
what I wanted, when I wanted.

David Botton

David Starner wrote in message <7vb3c4$8a21@news.cis.okstate.edu>...
>What stopped them from adopting something like that for
>Ada 95?

Re: Ammo-zilla

[mike]

In article <7vc2er$128q$1@news.gate.net>, "David says...
 
>I often wished when writing Java code that I could force the JVM to clean up
>what I wanted, when I wanted.
>
>David Botton
 
you can do that. just call the gc(). to clean you local objects, assign
'null' to them first. 

mike

Re: Ammo-zilla

[David Botton]

As pointed out before, that is just a hint to the VM, it doesn't guarantee
anything.

David Botton

mike@home wrote in message <7vco1c$ohs@drn.newsguy.com>...

>you can do that. just call the gc(). to clean you local objects, assign
>'null' to them first.

Re: Ammo-zilla

[Robert Dewar]

In article <7vco1c$ohs@drn.newsguy.com>,
  mike@home wrote:
> In article <7vc2er$128q$1@news.gate.net>, "David says...
>
> >I often wished when writing Java code that I could force the
JVM to clean up
> >what I wanted, when I wanted.
> >
> >David Botton
>
> you can do that. just call the gc(). to clean you local
objects, assign
> 'null' to them first.


No, as far as I know this is a seriously wrong claim. I believe
that it is still the case that some (many?) Java systems use
conservative garbage collection and thus do not guarantee to
free any memory ever (of course most of the time they will
free most garbage, they just can't guarantee to!)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ammo-zilla

[Charles Hixson]

Robert Dewar wrote:

> --    snip

> No, as far as I know this is a seriously wrong claim. I believe
> that it is still the case that some (many?) Java systems use
> conservative garbage collection and thus do not guarantee to
> free any memory ever (of course most of the time they will
> free most garbage, they just can't guarantee to!)
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

I believe this to be a -um- "valid" claim.  According to the reports
that I have heard, the Java (Sun, which version?) garbage collector
would collect garbage internally, but would never return the allocated /
collected space back to the operating system.  This would cause the
program to develop a very slow "leak".  I don't know how serious this
ever became (or, actually, even whether this was true) but this was the
claim.  So, in some sense, it never did collect and free any memory,
although the program was able to re-use it.

Re: Ammo-zilla

[Wes Groleau]

> I believe this to be a -um- "valid" claim.  According to the reports
> that I have heard, the Java (Sun, which version?) garbage collector
> would collect garbage internally, but would never return the allocated /
> collected space back to the operating system.  This would cause the
> program to develop a very slow "leak".  I don't know how serious this
> ever became (or, actually, even whether this was true) but this was the
> claim.  So, in some sense, it never did collect and free any memory,
> although the program was able to re-use it.

This was true of one Ada RTS five years ago, and a current user 
recently told me it's still true.  The vendor offered us as a "fix" a 
file containing a pragma that made "new" and unch. deall. call malloc 
and free, respectively!  In fact, this vendor's RTS was even worse--free 
list was never defragmented (coalesced, whatever you want to call it) so 
that if your allocations varied in size much, you would eventually have 
NO blocks big enough for another allocation.

Re: Ammo-zilla

[Geoff Bull]

mike@home wrote:
> 
> In article <7vc2er$128q$1@news.gate.net>, "David says...
> 
> >I often wished when writing Java code that I could force the JVM to clean up
> >what I wanted, when I wanted.
> >
> >David Botton
> 
> you can do that. just call the gc(). to clean you local objects, assign
> 'null' to them first.
> 
Explicitly calling the GC is VERY expensive, so you really
don't want to do it more often than necessary - and
the JVM knows when it is necessary.

For the Java I write, performance is important, and I find
myself programming to avoid the GC.
For "hot" classes I allocate a pool of objects up front,
then reuse them, instead of leaving them to the GC.
I also give the JVM heaps of memory.

BTW, has anybody noticed that Java finalization is broken.
System.runFinalizersOnExit is deprecated, so you can't
tell if finalizers will ever be run - making them almost
completely useless.

Re: Ammo-zilla

[Matthew Heaney]

In article <7vb3c4$8a21@news.cis.okstate.edu> , dvdeug@x8b4e53cd. (David 
Starner) wrote:

> And as long as you can't depend on it, GC's main advantage - saving the
> programer trouble worring about memory - is useless.

But only to the extent that you want portability across Ada compilers.
If you're willing to marry a specific compiler, then there's no reason
not to depend on GC.

Your argument rests on an unstated assumption, which is that you have to
be portable.  Change that assumption, and your argument is refuted.

Portability is an engineering decision.  Different shops and different
applications will make different choices.

--
The political forces that try to eliminate evolution from science
classrooms impose a narrow, sectarian doctrine on our educational
systems. This imposition represents an affront not only to the
constitutional separation of church and state but also to the moral and
intellectual integrity embedded in that constitution.

<http://www.nabt.org/evolutionks.html>

Re: Ammo-zilla

[Charles Hixson]

The real problem is not that is doesn't reliably exist, it's that it doesn't
have a well defined interface.  An optional annex could solve this.  There
would need to be a required test to determine whether or not it was present,
and a well defined interface to use if it were.  Then each program could
decide what to do if it were or were not present.  As it is... one MUST
depend on idiosyncratic behavior which is non-portable.  And I *do* want to
write portable applications, to the extent possible, given the trade-offs
necessary.

Matthew Heaney wrote:

> In article <7vb3c4$8a21@news.cis.okstate.edu> , dvdeug@x8b4e53cd. (David
> Starner) wrote:
>
> > And as long as you can't depend on it, GC's main advantage - saving the
> > programer trouble worring about memory - is useless.
>
> But only to the extent that you want portability across Ada compilers.

Re: Ammo-zilla

[Tucker Taft]

David Starner wrote:
> ...
> As a side question: Ada 95's designers must have been familiar with Modula 3's
> support of garbage collection while letting real time stuff keep track of
> its own memory. What stopped them from adopting something like that for
> Ada 95?

Another good question...

First, I agree with you that you can't really depend on garbage
collection in a langauge until essentially all implementations provide it,
so saying that it is allowed is sort of irrelevant.  On the other hand,
if you happen to be focusing on the Ada->JVM target, you can presume that
all implementations (there are only 2 so far) will provide garbage collection,
as it is built in to the JVM.

One choice you have is to use the third-party "conservative" garbage
collectors, essentially the same choice as provided by C++.  These
work with the same caveats in both Ada and C++.

As far as why we didn't have garbage collection for some kinds of
memory, and not for others, it was a question of demand, and perceived
cost/benefit ratio for a language focused on "critical" systems.  Prior to
the arrival of Java, garbage collection was definitely not "mainstream."
In the long run, making garbage collection a "mainstream" language feature
may be Java's biggest contribution to the history of programming language
usage.

On the other hand, our local experience with Java and garbage collection
is that the value it provides is greatest during prototyping.  Once you
get serious about scalability and performance, you have to go back to
being extremely careful about unnecessary object creation, and about 
effectively "freeing" objects (by nulling-out pointers) as soon as possible.
It is true that you don't have to worry about freeing memory too soon,
but you do have to worry about making sure that objects do not remain
unintentionally "reachable."

Personally, I think garbage collection is a way-station toward some
better as-yet-to-be-determined approach.  There are some interesting
languages and languge-theories out there that are based on single-point-of-
access to objects.  The language Hermes (nee' "Nil") by Strom et al had
this as their fundamental storage management approach.  It makes a lot
of sense for distributed and/or multi-threaded computing, because it
addresses storage management, synchronized access, and distribution
in one nice package.

Getting back to your original question about why not have garbage collection
for some kinds of objects, and not for others.  Once storage management gets
this sophisticated, it begins to become more of a "programming problem" than
a "language problem."  There were bad experiences with Ada 83 when the
language tried to get too high-level, to the point where the programmer
had no intuition about the implementation model of the language feature,
and implementations varied widely in the relative performance characteristics
of different features.  

Ideally, the ability to do garbage collection could be 
handed over to the programmer in a way that allowed them to
carve up the overall heap space into separate pools with different
management approaches in each, and then the programmer, or some third
party, would provide managers for these various spaces.  We took a baby-step
in that direction with the Storage_Pool attribute, but we didn't feel
confident in doing too much invention in this area.  Luckily, the
Ada language design process is much more dynamic now than it was in the
period from 1983 to 1990, so as good ideas are proposed and prototyped
(perhaps using GNAT), there is a very real chance that they will evolve
into parts of the standard.  

I know that some users of Ada 95 have built quite elaborate 
garbage collectors on top of the Storage_Pool facility
(e.g. the garbage collection built into the ORBExpress/Ada product built
by Objective Interface Systems).  Perhaps their experience will enable
us to develop a more complete user-controlled garbage collection capability
for future standardization.  

For this to be most useful, there *will* need to be a 
garbage-collecting storage pool manager defined as part of
the standard, so it may be used in all Ada code, not just in code written
for a compiler that happens to include one.  Certainly a key requirement
will be that this garbage-collecting manager is not forced on all Ada
users, and that it is replacable by the programmer or a third party without
having to go back to the compiler vendor, and without having to dismember
the rest of the run-time system.  It would not be acceptable to follow
the Java approach, where garbage collection is an integral part of the
JVM, with no well defined way to avoid it or replace it without essentially
rewriting the JVM. 

> --
> David Starner - dstarner98@aasaa.ofe.org

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Ammo-zilla

[Lutz Donnerhacke]

* Tucker Taft wrote:
>For this to be most useful, there *will* need to be a 
>garbage-collecting storage pool manager defined as part of
>the standard, so it may be used in all Ada code, not just in code written
>for a compiler that happens to include one.

Fine. All work the compiler crew does fine saves hundreds of hours in
programmer's cubicles and uncountable hours of bug fixing at customers end.

Re: Ammo-zilla

[Robert Dewar]

In article <7vb3c4$8a21@news.cis.okstate.edu>,
  dvdeug@x8b4e53cd. (David Starner) wrote:
> I said nothing about vendors. As long as there are
> otherwise-reasonable Ada compilers that don't garbage collect,
> good Ada programs must assume they're running on that system.

I strongly object to this. There are many optional features in
Ada, including for example the entire information systems
annex, or complex arithmetic in annex G. It is absolutely
perfectly reasonable to write Ada programs using these
optional features providing that you have a clear understanding
of the requirements you place on the Ada compiler as you do it.

> I once pointed out that integer'base could be an infinite
> precision integer type. (Robert Dewar said yes, but it wasn't
> something that was going to get added to GNAT.)

More accurately, he said that it would not be added unless
there was significant customer demand -- there is none!

> Let's say that it was added to GNAT.
> Good portable Ada code still couldn't depend on having 70
> digit+  integer types.

There is nothing bad about Ada code that depends on optional
features of Ada. Do you really think that any Ada code that
uses tasking priorities is bad? Of course not!!! It is just
that such code requires an Ada compiler that implements this
optional Ada feature.

> As a side question: Ada 95's designers must have been familiar
> with Modula 3's support of garbage collection while letting
> real time stuff keep track of its own memory. What stopped
> them from adopting something like that for Ada 95?

They were quite familiar, they were unconvinced (perhaps they
were unaware of any significant examples of large mission
critical real time systems implemented in Modula-3 that they
found convincing :-) :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Garbage colletion

[Lutz Donnerhacke]

* Robert Dewar wrote:
>More accurately, he said that it would not be added unless
>there was significant customer demand -- there is none!

This typ of reasoning is invalid, because a customer who learned to deal
with a missing feature clearly does not need it afterwards. This is
especially true after all programming examples which required GC are deleted
from the hard disk. (Although they were smaller and easier to understand.)
\f
This is no cry for GC.

Re: Garbage colletion

[Robert Dewar]

In article <slrn81osi4.940.lutz@belenus.iks-jena.de>,
  lutz@iks-jena.de (Lutz Donnerhacke) wrote:
> * Robert Dewar wrote:
> >More accurately, he said that it would not be added unless
> >there was significant customer demand -- there is none!
>
> This typ of reasoning is invalid, because a customer who
learned to deal
> with a missing feature clearly does not need it afterwards.
This is
> especially true after all programming examples which required
GC are deleted
> from the hard disk. (Although they were smaller and easier to
understand.)
>
> This is no cry for GC.

Actually that last comment is a bit confusing, because the
particular issue on which I made the comment you quote above
was infinite precision integers :-) :-)

Of course you can also claim the above reasoning is invalid for
those as well, and indeed your general argument applies to
absolutely any neat idea that anyone might have under any
circumstance, but we need a better discriminator for priorities
than this :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Garbage colletion

[Lutz Donnerhacke]

* Robert Dewar wrote:
>Of course you can also claim the above reasoning is invalid for
>those as well, and indeed your general argument applies to
>absolutely any neat idea that anyone might have under any
>circumstance, but we need a better discriminator for priorities
>than this :-)

No. It is only valid for problems which arise often enough to newusers.
Those problems are common enough to be included in a FAQ.

But the main argument against GC is, that real world problems would require
to cancel GC ;-)

Re: Garbage colletion

[Larry Kilgallen]

In article <slrn81osi4.940.lutz@belenus.iks-jena.de>, lutz@iks-jena.de (Lutz Donnerhacke) writes:
> * Robert Dewar wrote:
>>More accurately, he said that it would not be added unless
>>there was significant customer demand -- there is none!
> 
> This typ of reasoning is invalid, because a customer who learned to deal
> with a missing feature clearly does not need it afterwards. This is
> especially true after all programming examples which required GC are deleted
> from the hard disk. (Although they were smaller and easier to understand.)

Would you suggest that compiler vendors should specifically target
features their customers do not request ?

In preference to features their customers _do_ request ?

If adding perfect GC cost nothing, I am sure all vendors would
quite happily include it.

Personally, I am much more concerned with combatting defects
than with new features.

Larry Kilgallen

Re: Garbage colletion

[Robert Dewar]

In article <slrn81osi4.940.lutz@belenus.iks-jena.de>,
  lutz@iks-jena.de (Lutz Donnerhacke) wrote:
> * Robert Dewar wrote:
> >More accurately, he said that it would not be added unless
> >there was significant customer demand -- there is none!
>
> This typ of reasoning is invalid, because a customer who
> learned to deal with a missing feature clearly does not need
> it afterwards.

Well given the choice between implementing features that
customers are actively asking for, and those that none of
them are asking for, it is not hard to set priorities.
Certainly we do implement features that we feel are important
that are NOT on immediate want lists because we think that
in the long run they will be useful, but I am afraid that
at this point garbage collection does not get high on this
priority list either (we regard further work on our
integrated development environment for example to have
much higher priority).

Remember, that unlike most (but not all) the readers here, I
know the garbage collected "world" very well, having, as I noted
before been chairman of WG2.1 for many years, and having
developed the GC algorithms for SPITBOL. Personally I would
very much like to see someone develop a GC implementation for
GNAT!

Indeed, the most constructive thing would be for the GC
advocates to spend their time doing that instead of trying to
encourage "them" to do it :-) :-)

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Garbage colletion

[Lutz Donnerhacke]

* Robert Dewar wrote:
>Well given the choice between implementing features that
>customers are actively asking for, and those that none of
>them are asking for, it is not hard to set priorities.

Of course.

>Remember, that unlike most (but not all) the readers here, I
>know the garbage collected "world" very well, having, as I noted
>before been chairman of WG2.1 for many years, and having
>developed the GC algorithms for SPITBOL. Personally I would
>very much like to see someone develop a GC implementation for
>GNAT!

As a well implemented storage type in order to include it into a 'required'
appendix.

>Indeed, the most constructive thing would be for the GC
>advocates to spend their time doing that instead of trying to
>encourage "them" to do it :-) :-)

After learning Ada without GC most programmers learned to deal without it
and have some problems to solve. So there is really no need for GC ;-)

Re: Garbage colletion

[Robert Dewar]

In article <slrn81qgvs.mm.lutz@taranis.iks-jena.de>,
  lutz@iks-jena.de (Lutz Donnerhacke) wrote:
> After learning Ada without GC most programmers learned to deal
> without it and have some problems to solve. So there is really
> no need for GC ;-)

Well we agree more than you think here. I think if someone did
a general GC for GNAT, there would be lots of people interested
in it, and after all for many people, since GNAT is on pretty
much all machines, they don't mind not being portable to
non-GNAT compilers, so even if only GNAT did it, it would still
get a lot of use.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Garbage colletion

[Didier Utheza]

Oberon for Linux is using a garbage collector developed in C. The people
that created the compiler just interfaced the GC code to the Oberon
compiler. The code is avalaible to the public, the biggest problem with
Ada would be to reimplement the GC in native code in the logic of the
compiler, but regarding stability, this GC has a good rating!
Greeting.

On Mon, 1 Nov 1999, Robert Dewar wrote:

> In article <slrn81qgvs.mm.lutz@taranis.iks-jena.de>,
>   lutz@iks-jena.de (Lutz Donnerhacke) wrote:
> > After learning Ada without GC most programmers learned to deal
> > without it and have some problems to solve. So there is really
> > no need for GC ;-)
> 
> Well we agree more than you think here. I think if someone did
> a general GC for GNAT, there would be lots of people interested
> in it, and after all for many people, since GNAT is on pretty
> much all machines, they don't mind not being portable to
> non-GNAT compilers, so even if only GNAT did it, it would still
> get a lot of use.
> 
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.
> 
> 

Re: Garbage colletion

[David Starner]

On Thu, 4 Nov 1999 15:38:22 -0500, Didier Utheza <ddutheza@bu.edu> wrote:
>Oberon for Linux is using a garbage collector developed in C. The people
>that created the compiler just interfaced the GC code to the Oberon
>compiler. The code is avalaible to the public, the biggest problem with
>Ada would be to reimplement the GC in native code in the logic of the
>compiler, but regarding stability, this GC has a good rating!
>Greeting.

Considering how two other compilers based of GCC (gjc & gobjc) use it (the 
Boehm conservative collector), it probably will be the first compiler 
interfaced to GNAT. 

--
David Starner - dstarner98@aasaa.ofe.org

Gnat IDE (was: Garbage colletion)

[Ted Dennison]

In article <7vil9t$vmn$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <slrn81osi4.940.lutz@belenus.iks-jena.de>,

> priority list either (we regard further work on our
> integrated development environment for example to have
> much higher priority).

Interesting. I presume you would have portability as a major goal for
your IDE. So what are you basing the graphical part off of? Perhaps TK,
like was done for GDB/TK? Or are you taking the "Stallman" approach and
doing the whole thing in Emacs?

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ammo-zilla

[Robert Dewar]

In article <7vb3c4$8a21@news.cis.okstate.edu>,
  dvdeug@x8b4e53cd. (David Starner) wrote:
> As a side question: Ada 95's designers must have been familiar
> with Modula 3's support of garbage collection while letting
> real time stuff keep track of its own memory. What stopped
> them from adopting something like that for Ada 95?


By the way, speaking as someone quite familiar with garbage
collection (remember I chaired WG2.1 for many years, and
was responsible for the SPITBOL compilers -- see for example
the 1977 paper in SP&E that discusses a new GC algorithm used
very successfully in SPITBOL), I find the mixture of low level
system facilities, including those that let you break the type
model, and GC to be very worrisome, sounds like it can easily
create a debugging nightmare. Note that one of the reasons that
GC can succeed in Java is the extremely limited nature of the
language. GC is more practical in Ada if you severely restrict
the subset of Ada you support, and eliminate for instance
stuff like Unchecked_Conversion and address overlays.

What for instance does it mean to do address overlays that
reference the address of some object if the address of that
object changes due to GC? I have no idea what a sensible answer
to this question might be!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ammo-zilla

[David Starner]

On Sun, 31 Oct 1999 13:26:48 GMT, Robert Dewar <robert_dewar@my-deja.com> wrote:
>What for instance does it mean to do address overlays that
>reference the address of some object if the address of that
>object changes due to GC? I have no idea what a sensible answer
>to this question might be!

Um, don't move it? Either pick a form of GC that doesn't move objects
(the Boehm conservative GC is one that almost becoming the standard
for free software, while GCC now uses a rather more sophisticated GC
internally that doesn't move stuff), or mark that object as immobile.

--
David Starner - dstarner98@aasaa.ofe.org

Re: Ammo-zilla

[Robert Dewar]

In article <7vht9i$a2g1@news.cis.okstate.edu>,
  dvdeug@x8b4e53cd. (David Starner) wrote:
> or mark that object as immobile.

That enormously raises the complexity of a compacting garbage
collector, and these things MUST be 100% error free, because
bugs in garbage collectors are extremely scary!


Sent via Deja.com http://www.deja.com/
Before you buy.

Ada and GC. Was: Re: Ammo-zilla

[Vladimir Olensky]

David Starner wrote in message <7vht9i$a2g1@news.cis.okstate.edu>...
>On Sun, 31 Oct 1999 13:26:48 GMT, Robert Dewar <robert_dewar@my-deja.com>
wrote:
>>What for instance does it mean to do address overlays that
>>reference the address of some object if the address of that
>>object changes due to GC? I have no idea what a sensible answer
>>to this question might be!
>
>Um, don't move it? Either pick a form of GC that doesn't move objects
>(the Boehm conservative GC is one that almost becoming the standard
>for free software, while GCC now uses a rather more sophisticated GC
>internally that doesn't move stuff), or mark that object as immobile.



Such problem exists only  in the systems where everything
is garbage collected.

1. In a system that gives you a choice to use TRACED or UNTRACED
by GC objects just do not use TRACED objects if you don't want
them to be moved by GC from one memory location to another.
Ada 95 is a system that was designed to allow that.

2. Even if object is TRACED by GC it is possible to use a scheme
 that does not modify memory reference of the TRACED object that
 is visible to client.
    Such scheme may  use  Address Descriptor Table for indirect object
reference within GC managed storage pool. This table is part of the
GC storage pool manager.
   Each entry of such table could keep  actual memory location of the
referenced
object and all the additional information that is needed to manage that
object.
( e.g  - Ref_Count field for simple reference counting GC).
  With such approach client knows only address of Address Descriptor Table
entry
for that particular object and the last one does not change when object is
moved to
the new memory location.
   There is nothing new in that. It is similar to the protected memory
access
 in operating systems  that run in a protected mode. Address of the object
is
 just address of the descriptor table entry for that object and the system
itself
calculates actual memory address of the referenced object.

What is more important such approach provides single_ point_ of_ access
for TRACED by GC objects. This in turn could make many things more easy.

Regards,
Vladimir Olensky

Re: Ada and GC. Was: Re: Ammo-zilla

[Tucker Taft]

Vladimir Olensky wrote:
> ...
> 1. In a system that gives you a choice to use TRACED or UNTRACED
> by GC objects just do not use TRACED objects if you don't want
> them to be moved by GC from one memory location to another.

By the way, don't you generally need to do reference
counting rather than tracing-based GC if you have some
traced and some untraced objects?  If not, how do you deal with
pointers to traced objects that exist in untraced objects?
(Perhaps disallow at compile-time?)

> ...
> Regards,
> Vladimir Olensky

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Ada and GC. Was: Re: Ammo-zilla

[Vladimir Olensky]

Tucker Taft wrote in message <381DD258.B6B11153@averstar.com>...
>Vladimir Olensky wrote:
>> ...
>> 1. In a system that gives you a choice to use TRACED or UNTRACED
>> by GC objects just do not use TRACED objects if you don't want
>> them to be moved by GC from one memory location to another.
>
>By the way, don't you generally need to do reference
>counting rather than tracing-based GC if you have some
>traced and some untraced objects?  If not, how do you deal with
>pointers to traced objects that exist in untraced objects?
>(Perhaps disallow at compile-time?)


To be clearer I just used Modula-3 terminology that uses UNTRACED
 keyword to denote  REF TYPES that are pointers that are not
controlled by the GC. So in this context TRACED word denotes
 pointers that are controlled by GC and nothing more (it does not
imply any GC mechanism).

So I was saying that if one uses TRACED REF TYPE (default in M3)
or in Ada "TRACED" ACCESS TYPE that means that this access
type and operations with it are provided by the particular
GC_storage_manager and that  "TRACED" ACCESS TYPE is under
full control of that GC manager. This GC_Pointer is of
Ada.Finalization.Controlled type.

GC manager provides Initialize, Adjust and Finalize operations for
the "TRACED" ACCESS TYPE that it exports. Another operation
is Create (GC_Ptr, Object_Type)  that returns instance of that
"TRACED" ACCESS TYPE which essentially is reference to the entry
in GC Address Descriptor Table for the created object. That table entry
may contain other information needed to implement particular GC
management mechanism (it may be Reference_Count field for reference
counting mechanism or may be something else).
How pool management is implemented is  private matter
of that GC storage manager.

So idea is that externally GC provides control over
"TRACED" ACCESS TYPES via Initialize, Adjust
and Finalize operations and internally over allocated
objects referenced by  "TRACED" ACCESS TYPES
as well as dereferencing operations.

Taking all that into consideration it does not matter where
such "TRACED" ACCESS TYPE object (GC_Pointer) is located.
Nulling-out such pointer or freeing any dynamically allocated object
(which may be allocated by another GC manager) where such
GC_Pointer is located will automatically reclaim storage when
GC manager will see that there is no more references
to the allocated object.

As I mentioned in my other post when using such kind of storage
pool controlled by GC via it's Address Descriptor Table actual storage
pool may even be located on one or several remote machines that may
act as Objects Storage Servers for many other machines.
In this case local GC storage manager is a client of the remote
GC_Storage_Server and we will have some kind of
NETWORK_WIDE_VIRTUAL_GARBAGE_COLLECTED_MEMORY.

May be I am wrong somewhere. I am not a big expert in GCs.
I just let my imagination go where it wants to go.

Regards,
Vladimir Olensky

Re: Ada and GC. Was: Re: Ammo-zilla

[Robert Dewar]

In article <381DD258.B6B11153@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
> By the way, don't you generally need to do reference
> counting rather than tracing-based GC if you have some
> traced and some untraced objects?  If not, how do you deal
> with
> pointers to traced objects that exist in untraced objects?
> (Perhaps disallow at compile-time?)

A general note here is that the Algol-68 literature contains
a very thorough treatment of garbage collection in languages
of this level, including a full treatment of real-time issues.
This literature seems often ignored these days, and I see people
reinventing square wheels all the time, especially in the Java
context.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada and GC. Was: Re: Ammo-zilla

[Charles Hixson]

Given that Ada packages (or at least their private areas) are separate
from the rest of the code:
garbage collection could achieve almost all of it's desired ends if the
implementation of garbage collection within a package *required* that
unchecked de/allocation (and other unsafe constructions) not be used
within that package.
This would allow dynamic constructions that were isolated into separate
packages to co-exist with their more consicously manipulated brethern
within the same program.

Re: Ada and GC. Was: Re: Ammo-zilla

[Robert Dewar]

In article <381F7FFA.FFF5A906@mail.earthlink.net>,
  Charles Hixson <charleshixsn@mail.earthlink.net> wrote:
> This would allow dynamic constructions that were isolated into
separate
> packages to co-exist with their more consicously manipulated
brethern
> within the same program.

I don't see how this will help at all unless you partition
memory into sections that cannot contain mutual pointers ...



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada and GC. Was: Re: Ammo-zilla

[Charles Hixson]

Well... I was thinking that within the {Pragma GC} packages at a minimum
the compiler should be able to readily determine which items were
pointers and which were not.  This would put contraints on type casts
(generally a good thing anyway, even if they are sometimes needed), etc.

Actually, I was thinking of imposing even stronger limitations, (only
manage storage allocated within the package, pass return values out as
function values, but no direct access allowed, no publicly visible
access variables, any child packages to be subject to GC constraints,
etc.).  Even if the packages are limited in this manner, most of the
advantages of GC can be obtained.  If they aren't all needed, then so
much the better.

The idea here is, when one wants to make use of an efficient GC, then
one adopts such constraints as are necessary to make it easy and
efficient.  But one is able to freely link it to other sections of code
that don't have those constraints, so that one can do the parts that it
would be difficult to do in the limited framework in a more liberal
environment.  One just needs to be much more careful with allocated
storage when not inside the GC section of the code.  And, yes, their use
of memory would be nearly disjoint.  But this would allow much simpler
algorithms to be used for lattice memory structures, etc.  And would
allow most of the code to be written in the normal manner.  I may feel
that code would tend to migrate to the GC section, but this would not be
a necessity, and certainly the non-GC sections of the code could be
expected to be faster.


Robert Dewar wrote:

> In article <381F7FFA.FFF5A906@mail.earthlink.net>,
>   Charles Hixson <charleshixsn@mail.earthlink.net> wrote:
> > This would allow dynamic constructions that were isolated into
> separate
> > packages to co-exist with their more consicously manipulated
> brethern
> > within the same program.
>
> I don't see how this will help at all unless you partition
> memory into sections that cannot contain mutual pointers ...
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Re: Ada and GC. Was: Re: Ammo-zilla

[Vladimir Olensky]

Vladimir Olensky wrote in message ...

>2. Even if object is TRACED by GC it is possible to use a scheme
> that does not modify memory reference of the TRACED object that
> is visible to client.
>    Such scheme may  use  Address Descriptor Table for indirect object
>reference within GC managed storage pool. This table is part of the
>GC storage pool manager.


 < ....>

>What is more important such approach provides single_ point_ of_ access
>for TRACED by GC objects. This in turn could make many things more easy.



One more thing that I forgot to mention:

In addition to all said above this approach allows to create
TRACED by GC objects not only on local machine but
also on any remote machine within distributed application.
It is just matter of how that Descriptor Table and associated
operations  are constructed.
  So for example it is possible to have high speed LAN
(gigabits per seconds data rate) where some machines
can serve as Objects Storage Servers which can be
accessed by Applications Servers from different
machines.  Kind of distributed virtual memory.

Or such table and GC manager could  incorporate
CORBA for doing remote object management.

All that may be done with needed level of sophistication
which would be hidden from the client.

May be all that  is already done somewhere.
If so then it would be nice for such experience
to be shared by others ( e.g. via Adapower)

Regards,
Vladimir Olensky

Re: Ammo-zilla

[Robert Dewar]

In article <7vht9i$a2g1@news.cis.okstate.edu>,
  dvdeug@x8b4e53cd. (David Starner) wrote:
> Um, don't move it? Either pick a form of GC that doesn't move
> objects

That's very restrictive of course, and means you do not get
page relocalization effects, which can be significant.

> (the Boehm conservative GC is one that almost becoming the
standard
> for free software,

Conservative GC is very dubious for any mission critical
software that has to worry about memory leaks. The idea that
any arbitrary object MIGHT fail to be released as a result of
bad luck is unacceptable in any environment where you have to
be careful about limited memory.

> while GCC now uses a rather more sophisticated GC
> internally that doesn't move stuff), or mark that object as
> immobile.

Well of course it is MUCH easier to introduce this kind of
specialized GC, you should be able to do the same in Ada by
simply defining an appropriate storage pool.



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ammo-zilla

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> By the way, speaking as someone quite familiar with garbage
> collection (remember I chaired WG2.1 for many years, and
> was responsible for the SPITBOL compilers -- see for example
> the 1977 paper in SP&E that discusses a new GC algorithm used
> very successfully in SPITBOL), I find the mixture of low level
> system facilities, including those that let you break the type
> model, and GC to be very worrisome, sounds like it can easily
> create a debugging nightmare. Note that one of the reasons that
> GC can succeed in Java is the extremely limited nature of the
> language. GC is more practical in Ada if you severely restrict
> the subset of Ada you support, and eliminate for instance
> stuff like Unchecked_Conversion and address overlays.
> 
> What for instance does it mean to do address overlays that
> reference the address of some object if the address of that
> object changes due to GC? I have no idea what a sensible answer
> to this question might be!

I think most languages (or implementations thereof) today that support
garbage collection also have interfacing-to-C capabilities, which
introduces all the issues you're worried about.  If you pass pointers
into the C world, you end up pinning down objects "by hand" and so
forth, and yes, it is error prone and possibly inefficient.

I understand your concern, but I don't think it's all that bad -- I
don't think it's unreasonable to have Unchecked_Conversion of pointers
and garbage collection in the same language.  You have to be careful,
and you have to minimize and isolate the low-level stuff.  After all,
the mere existence of Unchecked_Conversion doesn't cause any problems --
you have to *use* it to cause trouble, and that's a programmer's choice.

- Bob

Re: Ammo-zilla

[Vladimir Olensky]

Robert A Duff wrote in message ...
>Robert Dewar <robert_dewar@my-deja.com> writes:


>I understand your concern, but I don't think it's all that bad -- I
>don't think it's unreasonable to have Unchecked_Conversion of pointers
>and garbage collection in the same language.  You have to be careful,
>and you have to minimize and isolate the low-level stuff.

^^^^^^^^^^^^^^^^^^^^^^^
In  a package that could be marked as UNSAFE ( Modula-3
approach to safety problem) or using "Pragma Unsafe".

It would be nice to have such package marker as well as
SAFE marker.

SAFE marker is simpler to use than put
 a whole bunch of pragmas:
    pragma restrictions(AAA)
    pragma restrictions(BBB)
    ......
    pragma restrictions(ZZZ)

One can use that marker for completely safe packages.

Otherwise UNSAFE marker could allow even more
low-level unsafe operations.

Regards,
Vladimir Olensky

Re: Ammo-zilla

[Robert Dewar]

In article <wcc66zmnw0h.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> I understand your concern, but I don't think it's all that bad
-- I
> don't think it's unreasonable to have Unchecked_Conversion of
pointers
> and garbage collection in the same language.  You have to be
careful,
> and you have to minimize and isolate the low-level stuff.
After all,
> the mere existence of Unchecked_Conversion doesn't cause any
problems --
> you have to *use* it to cause trouble, and that's a
programmer's choice.


Well do you understand the concern? Have you done debugging in
this kind of environment? I have!

A bug that damages the integrity of the collection mechanism can
often take many garbage collection cycles to make itself known,
spreading like a kind of cancer at each garbage collection
cycle. Furthermore, the result might just be a subtle memory
leak, particularly hard to detect, when the real reason for the
problem has been disposed of many GC cycles ago.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ammo-zilla

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> Well do you understand the concern? Have you done debugging in
> this kind of environment? I have!

Not a whole lot, but I have written mixed Smalltalk and assembly
language, and yes, bugs were very nasty once in a while, because the GC
destroys the evidence.  But if the total amount of assembly is
reasonably small, and you know you have a "weird" bug, you can stare at
the assembly very carefully until you see it.  Or you can set options on
the GC that tell it to run more often (so you might get lucky and trip
over the bug sooner), or whatever.

I've also had experience with mixed Simula and Pascal, and with pure
assembly with some ad hoc sort of GC of some data structures.

But I've also seen some pretty nasty bugs in non-GC'ed systems, so...

In any case, in a garbage-collected system, somebody has to write the
garbage collector itself, and that fundamentally requires the kind of
low-level features we're talking about -- the GC obviously can't rely on
the existence of GC.  Bugs in the GC itself have exactly the same sort
of nasty consequences we're talking about.

> A bug that damages the integrity of the collection mechanism can
> often take many garbage collection cycles to make itself known,
> spreading like a kind of cancer at each garbage collection
> cycle. Furthermore, the result might just be a subtle memory
> leak, particularly hard to detect, when the real reason for the
> problem has been disposed of many GC cycles ago.

- Bob

Re: Ammo-zilla

[Robert Dewar]

In article <wcck8o0yh5x.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
>  Bugs in the GC itself have exactly the same sort
> of nasty consequences we're talking about.

Absolutely! And that's what's scary! These bugs in the GC itself
are among the most horrible bugs I have ever tackled (the one
exception being subtle hardware design errors). The idea that
an Ada user with little awareness of what is going on at a low
level can create bugs of comparable scariness by casual
incorrect use of unchecked conversion seems unacceptably
risky to me.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ammo-zilla

[Vladimir Olensky]

Robert Dewar wrote in message <7vncgr$bpg$1@nnrp1.deja.com>...
>In article <wcck8o0yh5x.fsf@world.std.com>,
>  Robert A Duff <bobduff@world.std.com> wrote:
>>  Bugs in the GC itself have exactly the same sort
>> of nasty consequences we're talking about.
>
>Absolutely! And that's what's scary! These bugs in the GC itself
>are among the most horrible bugs I have ever tackled (the one
>exception being subtle hardware design errors). The idea that
>an Ada user with little awareness of what is going on at a low
>level can create bugs of comparable scariness by casual
>incorrect use of unchecked conversion seems unacceptably
>risky to me.


As for me I fully support that.
I think that any unchecked conversions should
be disallowed for pointers that are traced by GC.
It is not only extremely unsafe but I do not see any sense
in that if language is extended to support GC.

Any manipulations with such pointers should be allowed only
within GC manager package. GC client should not have any access
to such operations at all. GC mechanism should be completely
hidden from the client. Depending on particular GC
mechanism any pointer traced by GC may be not only a pure
"ROOT" (in traditional GC terminology)  which  references object
storage location but it may also be a reference  to the entry
record in GC Address Descriptor Table which in turn in one
of it's fields contains  the real "ROOT" of the pointers tree/net
as well as other necessary fields (referenced object tag, size etc.).
Last approach  was described in my other posts.
For such GC_Pointer unchecked conversions done by
the client makes no sense at all.

This restriction could be done using  language support for GC.
Let's suppose that we have additional keyword TRACED
that applied to the ACCESS TYPES controlled by GC.
(This TRACED ACCESS TYPE could be bound
to particular GC using standard Ada construct:
for T'Storage_Pool use Ada.GC.GC_Name_Storage_Pool).

When access type is declared to be traced compiler should
not allow any unchecked conversions with that type in standard
mode.
In may allowed only using  additional pragmas.


Regards,
Vladimir Olensky

Re: Ammo-zilla

[Robert Dewar]

In article <s20tckqd24291@corp.supernews.com>,
  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
> As for me I fully support that.
> I think that any unchecked conversions should
> be disallowed for pointers that are traced by GC.
> It is not only extremely unsafe but I do not see any sense
> in that if language is extended to support GC.

But that of course is not enough to prevent scary GC bugs :-)

As soon as you allow the type safety of the system to be
compromised in any way, it is possible that critical pointers
will get damaged.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada GC (was Re: Ammo-zilla)

[Vladimir Olensky]

Robert Dewar wrote in message <7vqd45$iiq$1@nnrp1.deja.com>...
>In article <s20tckqd24291@corp.supernews.com>,
>  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
>> As for me I fully support that.
>> I think that any unchecked conversions should
>> be disallowed for pointers that are traced by GC.
>> It is not only extremely unsafe but I do not see any sense
>> in that if language is extended to support GC.
>
>But that of course is not enough to prevent scary GC bugs :-)


Yes, I agree this does not prevent  GC bugs that may exist
in GC implementation itself.  But at least that could  provide
isolation between GC implementation and GC client.
The last one will never be able to spoil anything in GC
internal data.  Also, approach that I discribed yearlier
provides additional level of isolation  between GC user
and GC internal data representation and it also  allows
to achieve any desired level of sofisticated functionality .
 Any pointer  of  "TRACED" ACCESS TYPE  should never
reference real data.  Instead it should only provide access to
the  Address Descriptor Table entry for the allocated object .
Moreover,  Address Descriptor Table  structure is completely
hidden from the user. This is the same as protected
memory access in OS running in protected mode.
This already proved to be very effective in providing safety
and reliability.

>As soon as you allow the type safety of the system to be
>compromised in any way, it is possible that critical pointers
>will get damaged.


Again I agree here.
And again I would like to recall neat  Modula-3 approach to the
safety issues that could  also be  very useful  in Ada:
Any unsafe operations are allowed only in the modules marked
 as UNSAFE . This marker says that here programmer and not
the system is  responsible for safety. In modules without such
marker M3 does  not allow any unsafe operation and safety
is guaranteed by  the system itself.  Such approach force
all (potentially) unsafe operations to be concentrated in few
unsafe modules instead of being scatted around.
Right now nothing forces Ada programmer (except his/her
internal discipline) to concentrate all unsafe operation in special
packages.

This reminds me discussions  Ada vs. C& C++ where many times
many people were telling that Ada is better in this respect   than C++
as C++ does allow to use unsafe and dangerous C style programming
and does not force to use new more safe C++ features.

Yes, Ada is much  safer itself but it does not force as Modula-3
to put unsafe code in special places where such operations
could be easily traced and managed.

I think that some ideas implemented in M3 could be very useful in Ada .
There is nothing bad in using other's positive experience.
Here I could remind  that Component Pascal  (descendant of Oberon-2)
accepted some nice Ada features and they state that Ada positive
experiences were taken into account and that sounds good for me.

Regards,
Vladimir Olensky.

Re: Ada GC (was Re: Ammo-zilla)

[Robert Dewar]

In article <s23mnbp024223@corp.supernews.com>,
  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
>
> Robert Dewar wrote in message <7vqd45$iiq$1@nnrp1.deja.com>...
> >In article <s20tckqd24291@corp.supernews.com>,
> >  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
> >> As for me I fully support that.
> >> I think that any unchecked conversions should
> >> be disallowed for pointers that are traced by GC.
> >> It is not only extremely unsafe but I do not see any sense
> >> in that if language is extended to support GC.
> >
> >But that of course is not enough to prevent scary GC bugs :-)
>
> Yes, I agree this does not prevent  GC bugs that may exist
> in GC implementation itself.  But at least that could  provide
> isolation between GC implementation and GC client.
> The last one will never be able to spoil anything in GC
> internal data.

Again you miss my point, unless you segregate memory with
hardware memory protect, allowing unchecked conversion, and
hence address calculations, anywhere, can damage data structures
anywhere. I am NOT talking about bugs in the GC implementation
itself.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada GC (was Re: Ammo-zilla)

[Vladimir Olensky]

Robert Dewar wrote in message <7vvroo$grr$1@nnrp1.deja.com>...
>In article <s23mnbp024223@corp.supernews.com>,
>  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
>>
>> Robert Dewar wrote in message <7vqd45$iiq$1@nnrp1.deja.com>...
>> >In article <s20tckqd24291@corp.supernews.com>,
>> >  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
>> >> As for me I fully support that.
>> >> I think that any unchecked conversions should
>> >> be disallowed for pointers that are traced by GC.
>> >> It is not only extremely unsafe but I do not see any sense
>> >> in that if language is extended to support GC.
>> >
>> >But that of course is not enough to prevent scary GC bugs :-)
>>
>> Yes, I agree this does not prevent  GC bugs that may exist
>> in GC implementation itself.  But at least that could  provide
>> isolation between GC implementation and GC client.
>> The last one will never be able to spoil anything in GC
>> internal data.
>
>Again you miss my point, unless you segregate memory with
>hardware memory protect, allowing unchecked conversion, and
>hence address calculations, anywhere, can damage data structures
>anywhere. I am NOT talking about bugs in the GC implementation
>itself.


I see your point now.

Of course it is very dangerous to perform any calculations (e.g address
arithmetic) for something that is hidden behind protection wall and one
does not know for sure what is there in reality.
This is especially dangerous when different kinds of memory pools are
mixed and one does not know for sure on which kind of memory one
is trying to perform such operations.

It just never come to my mind that someone (one the client's side)
could try to do something (using unchecked conversions ) for anything
that is behind that protection wall  (for me it is a crazy idea).

Mapping between external world and internal world relative to that wall
could
only be allowed to the subsystem responsible for that protection wall.

As a matter of fact  I do not see the way how one can penetrate in reality
through hardware memory protection wall directly using pointer arithmetic.
One need to have access to some system resources to do that. But if one
could perform such operations with the virtual addresses on this side of the
wall and if one does not know how they map to the real physical addresses
it could cause problems.

On the other hand you already pointed out the way to reduce that danger:
".. unless you segregate memory with hardware memory protect ..".

Here I could also add that I think that it is not too dangerous  to perform
address arithmetic within single allocated chunck of memory providing that
measures have been taken to ensure that the result is within memory
boundaries
of the allocated memory chunck.  Reading/Writing data using such resulting
address
could be dangerous of course.

It could be extremely dangerous to use address arithmetic trying to
calculate location
of the prev/next memory chunk or object in the memory if allocated memory
chunks
are not contiguous that could be the case when  using hardware protected
memory.

In the best case one will get GPF, in the worst case one may damage data
structures.

With some overhead some measures could be taken to check pointer validity
to increase safety. This could be  keeping (hashed) table/list of pointers
to allocated
objects  and use that table/list to check pointer validity . Here I should
mention  very
interesting example in GNAT distribution, namely  System.Debug_Pool package
that
makes use of  H-table to keep the status of each storage chunk used in that
pool.

Generally there could be many approaches to increase safety.
One of the nice ones (for me)  is to use notion of safe and unsafe
modules/packages as in Modula-3 and do not allow any unsafe
operations in safe packages.

Regards,
Vladimir Olensky

Re: Ada GC (was Re: Ammo-zilla)

[Vladimir Olensky]

> >> > Robert Dewar wrote in message <7vvroo$grr$1@nnrp1.deja.com>...
> >> >But that of course is not enough to prevent scary GC bugs :-)
> >>
> >> Yes, I agree this does not prevent  GC bugs that may exist
> >> in GC implementation itself.  But at least that could  provide
> >> isolation between GC implementation and GC client.
> >> The last one will never be able to spoil anything in GC
> >> internal data.
> >
> >Again you miss my point, unless you segregate memory with
> >hardware memory protect, allowing unchecked conversion, and
> >hence address calculations, anywhere, can damage data structures
> >anywhere. I am NOT talking about bugs in the GC implementation
> >itself.
>
> With some overhead some measures could be taken to check pointer
> validity  to increase safety. This could be done by keeping
> (hashed) table/list of pointers to allocated objects  and
> use that table/list to check pointer validity . Here I should
> mention  very  interesting example in GNAT distribution, namely
> System.Debug_Pools package that makes use of  H-table to keep
> the status of each storage chunk used in that pool.
>
> Generally there could be many approaches to increase safety.
> One of the nice ones (for me)  is to use notion of safe and unsafe
> modules/packages as in Modula-3 and do not allow any unsafe
> operations in safe packages.


Below is a small illustration to the topic discussed.

When using unchecked conversions it is very easy to damage data
even without pointer arithmetic.

As there is no way now to check VALIDITY of the pointer
then after unchecked conversion the result of doing such
conversion could be very disastrous.

Even if we try to check validity of the object's fields
which  is referenced by the new pointer this does not
help sometimes. Moreover if that pointer is Null then we
will have Constraint_Error or Program_Error exception.

This shows that for the safety reason applicability area of
the T'Valid attribute could be expanded at the expense of
some overhead in storage pool management to include validity
check for the given pointer that could be done as was
discussed in the previous posts.


Regards,
Vladimir Olensky

----------------------------------------------------
-- Demo:
-- Unchecked_Conversion -- bad usage that results in
-- data corruption
----------------------------------------------------

with Ada.Text_IO; use Ada.Text_IO;
with Ada.Integer_Text_IO; use Ada.Integer_Text_IO;
with Ada.Unchecked_Conversion;

procedure Tst_Acc_Validity is

   type T is
      record
         A : Integer;
         B : Integer;
      end record;

   type T_Ptr is access all T;

   type Enum is
         (Mon,
          Tue,
          Wed);

   package En_IO is new Ada.Text_IO.Enumeration_IO(Enum);

   type S is
      record
         A : String (1 .. 10) := " test test";
         B : Enum             := Tue;
      end record;

   type S_Ptr is access all S;

   function T_To_S_Ptr is
   new
      Ada.Unchecked_Conversion(T_Ptr,S_Ptr );

   T1 : T_Ptr;
   S1,
   S2 : S_Ptr;

begin

   T1 := new T'(
     A => 177,
     B => 555);

   S1:= T_To_S_Ptr(T1);

--   if S1'Valid then  ....
     --  no way do do this now, won't compile

   if S1.B'Valid then
      Put_Line(" S1.B is valid");
   else
      Put_Line(" S1.B is not valid");
   end if;
   --  does not show that S1.B is invalid

   New_Line;
   Put_Line("------------------------              Uncorrupted T1:");
   Put(" T1.A = ");
   Put(T1.A);
   New_Line;
   Put(" T1.B = ");
   Put(T1.B);
   New_Line;

   Put_Line("--------------------- Reading S1 from T1 memory area:");
   Put(" S1.A = ");
   Put(S1.A);
   New_Line;
   Put(" S1.B = ");
   En_IO.Put(S1.B);
   New_Line;

   S1.A:="write test";
   S1.B:=Wed;

   Put_Line("----- Writing S1 to T1 memory area and reading again:");
   Put(" S1.A = ");
   Put(S1.A);
   New_Line;
   Put(" S1.B = ");
   En_IO.Put(S1.B);
   New_Line;

   Put_Line("T1 is corrupted  after assigning values to S1 fields:");
   Put(" T1.A = ");
   Put(T1.A);
   New_Line;
   Put(" T1.B = ");
   Put(T1.B);
   New_Line;


   Put_Line("----------------------------- Checking S2.B validity:");
   --  could result in erroneous execution
   --  (LRM 13.11.2 (16): Evaluating a name that denotes a nonexistent
   --   object is erroneous)
   --  or raise Constraint_Error at a run time
   if S2.B'Valid then
      Put_Line(" S2.B is valid");
   else
      Put_Line(" S2.B is not valid");
   end if;


end Tst_Acc_Validity;


=============================================================
Progam output:

 S1.B is valid

----------------------------------              Uncorrupted T1:
 T1.A =         177
 T1.B =         555
------------------------------- Reading S1 from T1 memory area:
 S1.A = _   +\x02
 S1.B = MON
--------------- Writing S1 to T1 memory area and reading again:
 S1.A = write test
 S1.B = WED
--------- T1 is corrupted  after assigning values to S1 fields:
 T1.A =  1953067639
 T1.B =  1702109285
--------------------------------------- Checking S2.B validity:

raised CONSTRAINT_ERROR : tst_acc_validity.adb:95

Re: Ada GC (was Re: Ammo-zilla)

[Robert Dewar]

In article <s27tvo5hhpc65@corp.supernews.com>,
  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
> It just never come to my mind that someone (one the client's
> side) could try to do something (using unchecked conversions )
> for anything that is behind that protection wall  (for me it
> is a crazy idea).

I guess Vladimir that you have solved the problem that has
eluded everyone else in the field, namely how to be absolutely
sure that your program is free of errors. We are not talking
about DELIBERATE errors here, but for instance of a simple
error like using unchecked conversion to do low level buffer
copying, and getting the bounds wrong.

> As a matter of fact  I do not see the way how one can
> penetrate in reality through hardware memory protection wall
> directly using pointer arithmetic.

You are assuming that it is indeed possible to provide the
necessary memory protection between collected and non-collected
domains. First, my point was about systems
where this is not possible. Second: most systems are in practice
in this category!


> Generally there could be many approaches to increase safety.
> One of the nice ones (for me)  is to use notion of safe and
> unsafe modules/packages as in Modula-3 and do not allow any
> unsafe operations in safe packages.

But as we are discussing this segregation in what packages
are allowed to do is not helpful at all in this case in the
absence of the ability to build data allocation firewalls at
the hardware level (something that is often not possible,
both in embedded systems -- which often lack such memory
protection hardware -- and in higher level systems running
on top of standard OS's, which lack this kind of capability).


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada GC (was Re: Ammo-zilla)

[Robert A Duff]

"Vladimir Olensky" <vladimir_olensky@yahoo.com> writes:

> Robert Dewar wrote in message <7vvroo$grr$1@nnrp1.deja.com>...
> >Again you miss my point, unless you segregate memory with
> >hardware memory protect, allowing unchecked conversion, and
> >hence address calculations, anywhere, can damage data structures
> >anywhere. I am NOT talking about bugs in the GC implementation
> >itself.

And crossing a hardware protection boundary once for every "new" would
be prohibitively expensive (unless you designed the hardware
specifically to support such a thing -- even then, it would be
expensive).

> It just never come to my mind that someone (one the client's side)
> could try to do something (using unchecked conversions ) for anything
> that is behind that protection wall  (for me it is a crazy idea).

Bugs are not caused by people *trying* to do something -- they happen by
accident!

- Bob

Re: Ada GC (was Re: Ammo-zilla)

[Vladimir Olensky]

Robert A Duff wrote in message ...
>Bugs are not caused by people *trying* to do something -- they happen by
>accident!


Yes, no doubt that they happen by accident.

But sometimes they happen when someone  is trying  to do something
using unsafe features to achieve some goal that could not be achieved
using safe features and then something slips out of control (accidentally) .
And this happens not only in programming.

As far as access types concerned probability of such bugs could be
reduced if it would be possible to extend applicability of the VALID
attribute
to be used with some of the access types objects  (not all but at least for
some kind of  "TRACED" ACCESS TYPES  supported  by storage pools
with additional management overhead :-).

I feel that this could be very useful and it could make the idea behind
VALID
attribute to be more complete and more in line with the overall Ada
ideology.

Of course the same goal could be done by putting additional restrictions on
usage of some  unsafe features  but this idea leads to the direction that
were
followed by some other languages .
I feel that the better way (for general purpose programming)  is  to expand
applicability of the existing Ada safety features (making them more
complete).
VALID attribute falls in this category.

I am not insisting on all of that. I am just contemplating.


Regards,
Vladimir Olensky

Re: Ada GC (was Re: Ammo-zilla)

[Richard D Riehle]

Robert A Duff wrote in message ...
>Bugs are not caused by people *trying* to do something -- they happen by
>accident!

I usually tell my clients and students to stop using the word "bug"
entirely.  Software practice is the only engineering wannabee that
euphemizes away its mistakes by labeling them bugs.  

What we call a "bug" is actually a mistake.  Someone tried to do something
and made a mistake.  The mistake results in a defect.  The defect is a
potential run-time fault.   Managers need to take the responsibility for
elminating the word "bug" from the vocabulary of their software personnel.

There has been some discussion lately of software as an engineering 
practice.  It will not be an engineering discipline until we call a
mistake a mistake, forcing personnel to fully accept responsibility for
their errors of omission as well as commission.   A programmer calls it
a bug.  An engineer calls it a mistake.

Richard Riehle

Re: Ada GC (was Re: Ammo-zilla)

[Robert A Duff]

Richard D Riehle <laoXhai@ix.netcom.com> writes:

> I usually tell my clients and students to stop using the word "bug"
> entirely.  Software practice is the only engineering wannabee that
> euphemizes away its mistakes by labeling them bugs.  

Shrug.

I don't use the word "bug" as a euphemism.  Bugs are my enemy, and I
take them quite seriously.  I don't think renaming them "mistakes" or
"errors" or "disasters" would change people's attitudes.

- Bob

Re: Ada GC (was Re: Ammo-zilla)

[Nick Roberts]

Richard D Riehle wrote:
> ...
> There has been some discussion lately of software as an engineering
> practice.  It will not be an engineering discipline until we call a
> mistake a mistake, forcing personnel to fully accept responsibility for
> their errors of omission as well as commission.   A programmer calls it
> a bug.  An engineer calls it a mistake.

And, as a corollary, customers need to be educated into rejecting
software with a 'bug' in it just as diligently as they would reject any
other product with a defect.

It would help for our respective governments (UK, US, and elsewhere) to
produce some (not too heavy) legislation to assist in this (e.g.
outlawing some of the more outrageous evasions of liability in typical
software licences). Sadly, however, I think our politicians have
undergone a physical adaptation to their habitat (whereby the brain is
replaced by an air sac, for the more efficient generation of hot air).

-- 
Nick Roberts
Computer Consultant (UK)
http://www.callnetuk.com/home/nickroberts
http://www.adapower.com/lab/adaos

Re: Ada GC (was Re: Ammo-zilla)

[Robert Dewar]

In article <3829D562.5F102A83@callnetuk.com>,
  Nick Roberts <nickroberts@callnetuk.com> wrote:

> And, as a corollary, customers need to be educated into
> rejecting software with a 'bug' in it just as diligently as
> they would reject any other product with a defect.

Well, two points here.

One, to the extent that a bug reflects a difference between
the spec and the implementation, people are not that diligent,
and for good reason, insisting on defect free products would
increase their cost. Automobiles for instance virtually always
have delivery defects (See Consumer Reports, where it is quite
typical to see something like "this car was delivered in
excellent shape, there were only 17 defects, only one of them
significant").

Two, to the extent that a bug reflects something that people
don't like in the *design*, I think they are often more diligent
than for other products. You don't generally expect a car
maker to send you a new dashboard with the speedometer
positioned so you can see if it you are only 5'4" tall, but
in the software world, people expect this kind of
responsiveness. They don't always get it, but the expectations
that software can be improved in this way are greater than for
many other products.

At the same time, I think we all agree that the practice of
rushing things to market with entirely excessive numbers of
defects should be punished in the software area by consumer
rejection at least as energetically as for other fields.

The PC Junior was a bunch of junk, it rightly failed in the
marketplace.

By contrast, the decrepit version of DOS that Microsoft
delivered for use on the 286, which was incapable of taking
advantage of the 16 meg addressing and protected capabilities
of this chip was an abomination. But it succeeded in the
marketplace, despite the presence of a far superior product
from DR Research (Flex OS) that took full advantage of the
chip.

Why? Perhaps this has something to do with the stifling of
innovation that the recent finding of facts in the Microsoft
case describes in detail. Perhaps it is because consumers are
not educated to expect reasonable products in the software
area? WHo knows? But either way, it is indeed unacceptable.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada GC (was Re: Ammo-zilla)

[Robert I. Eachus]

Nick Roberts wrote:
  
> And, as a corollary, customers need to be educated into rejecting
> software with a 'bug' in it just as diligently as they would reject any
> other product with a defect.
> 
> It would help for our respective governments (UK, US, and elsewhere) to
> produce some (not too heavy) legislation to assist in this (e.g.
> outlawing some of the more outrageous evasions of liability in typical
> software licences). Sadly, however, I think our politicians have
> undergone a physical adaptation to their habitat (whereby the brain is
> replaced by an air sac, for the more efficient generation of hot air).

   Of course, any such well meaning legislation, if framed too broadly,
would do much more harm than good.  There are large categories of
software where applying techniques appropriate to saftey-critical
real-time software would make products unaffordably expensive.  But more
important there is a class of software where Godel's Proof guarentees
that there is at least one bug--like compilers--or where Post's
Correspondence Problem prevents proof of compliance with a particular
set of requirements.

   And then there are other problems, like the halting problem, where it
is possible to provide a useful implementation, but it is not possible
to provide a correct implementation of the requirements.

-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada GC (was Re: Ammo-zilla)

[Didier Utheza]

To return to the GC problem : as I understood the link, the problem
resides in the stability of the program and the compatibility of a GC with
a real time system. At the present time, this may actually be two
different matters.Just a pure question from a novice in Ada and OOP, can a
real time system accomodate the Object Oriented scheme without compromising its stability in the present state of
the technology? On the other side, Ada95 is a powerfull programming tool,
you can use it to create OSes, real time systems but also simpler programs
such as word processors and object oriented interfaces to human subject
instead of machine. In the last cases, GC could be acceptable. The time
penalty that it is bringing, will not be unacceptable.
So maybe a good way of introducing a GC in Ada would be to have a
conditional GC that can be turn on or off depending on the type of task
that the program is suppose to perform (non time critical and time
critical).
Greetings.

Re: Ada GC (was Re: Ammo-zilla)

[Robert I. Eachus]

Richard D Riehle wrote:
 
> What we call a "bug" is actually a mistake.  Someone tried to do something
> and made a mistake.  The mistake results in a defect.  The defect is a
> potential run-time fault.   Managers need to take the responsibility for
> elminating the word "bug" from the vocabulary of their software personnel.

    I have to disagree.  Yes, most bugs are mistakes, and are
determineded to be design errors or implementation errors.  However,
there are other categories of bug that do not involve mistakes.  For
example, ACT considers misleading error messages from the compiler to be
bugs.  I agree, but since the "right" error messages can only be
determined by experience, these bugs are usually not mistakes.

    As another example, failure to follow coding standards can be
mistakes.  But if the standard changes, or more likely code developed
with one standard is merged with code using a different standard, the
discrepancies are bugs.  (Not fixing them is a mistake, but at first
they are bugs.)  Similarly, if you are moving code forward to use a new
version of some COTS product, incompatibilies are bugs, but they are
normally not mistakes.

    These conditions are not limited to software.  For example, if your
job is to modify a transmission design to work with a different engine,
there may be many discrepancies to be resolved.  These were not
originally mistakes, and they will
only be potential faults if you fail to resolve them.  Or consider
circut board layout.  If your original try at laying out a board has 73
disconnects, it doesn't mean that you made 73 mistakes.  It may take you
days to reduce that number to zero (or in some cases to a small number
of wires), but that is part of the design process.

    Some people would go further and say that all potential faults
detected during unit test, or even integration test are not mistakes.  I
don't feel that all fall into that category, but there are certainly
cases where the job of integration is to resolve unintended conflicts
where there is no blame to be allocated.  Of course, one of the nice
things about Ada is that there are very few opportunities to innocently
create such conflicts.  On the other hand using a C++ compiler without
namespace support is a mistake, and the blame should be laid somewhere
if you get to integration and you have unrepairable naming conflicts.

-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada GC (was Ammo-zilla)

[Nick Roberts]

Vladimir Olensky wrote:
> ...
> This restriction could be done using  language support for GC.
> Let's suppose that we have additional keyword TRACED
> that applied to the ACCESS TYPES controlled by GC.
> (This TRACED ACCESS TYPE could be bound
> to particular GC using standard Ada construct:
> for T'Storage_Pool use Ada.GC.GC_Name_Storage_Pool).
> 
> When access type is declared to be traced compiler should
> not allow any unchecked conversions with that type in standard
> mode.
> In may allowed only using  additional pragmas.

Rather than introducing a new reserved word into the Ada syntax, I think
all that would be necessary would be for a new standard (abstract) pool
type to be defined, derived from Root_Storage_Pool, called
Root_Managed_Pool, say. Managed (garbage collecting) pools would all be
derived from this type. I think Root_Managed_Pool would have at least
one extra primitive operation, to induce a garbage collection and/or
object compaction cycle.

In order to cause objects referenced by a certain access type to be
allocated into a managed pool, one would simply declare a Storage_Pool
representation clause for the access type, naming an object of the
appropriate managed pool type. Notice how this leaves implementations
free to choose to provide garbage collection by default or not (or to
select this by pragma, compiler switch, or other option).

It would then be the responsibility of the compiler to ensure that all
objects of this access type were 'traced', as Vladimir puts it. This
means, in practice, that: a type descriptor for the access type must be
entered into a 'type descriptor table'; every single object of the
access type must be entered into a 'frame object table'; every instance
of a value of the access type being loaded into or saved out of a
register must be entered into a 'register loading table'; every compound
type which can contain one or more values of a traced type is also
traced (and so on recursively). The three tables would form part of the
static data of the program, and would enable managed pools to determine
the size and alignment of every object they contain, and to move those
objects about in memory, correcting variables and registers as
necessary. In addition, the compiler must provide facilities (to the
pool managers) for identifying and freezing those tasks using a managed
pool, for reading from and writing to the stack frames and register sets
of those tasks, etc. (Or, to put it in simpler terms, no-one should be
in doubt as to the complexity of adding GC, nor, for that matter, to the
possibility of doing so.)

It may well behove a compiler to issue a serious warning for any use of
unchecked conversion, deallocation, or access for any traced type. But
ultimately, as ever, if the user (Ada programmer) screws up, after
having been so warned, he or she only has himself or herself to blame.

It would undoubtedly be very useful (and not overly difficult, I think)
for the implementor of a managed pool to provide an alternative
implementation or mode which (sacrificing some efficiency perhaps)
provided various (extra) profiling and debugging facilities relating to
the use of the pool.

It would be particularly incumbent upon the implementors of managed
pools to make special efforts to ensure the correctness of their
implementations, since the results of a garbage collector going wrong
are always likely to be particularly unfortunate.

-- 
Nick Roberts
Computer Consultant (UK)
http://www.callnetuk.com/home/nickroberts
http://www.adapower.com/lab/adaos

Re: Ada GC (was Ammo-zilla)

[Wes Groleau]

> > This restriction could be done using  language support for GC.
> > Let's suppose that we have additional keyword TRACED
> > that applied to the ACCESS TYPES controlled by GC.
> > (This TRACED ACCESS TYPE could be bound
> > to particular GC using standard Ada construct:
> > for T'Storage_Pool use Ada.GC.GC_Name_Storage_Pool).
> >
> > When access type is declared to be traced compiler should
> > not allow any unchecked conversions with that type in standard
> > mode.
> > In may allowed only using  additional pragmas.
> 
> Rather than introducing a new reserved word into the Ada syntax, I think
> all that would be necessary would be for a new standard (abstract) pool
> type to be defined, derived from Root_Storage_Pool, called
> Root_Managed_Pool, say. Managed (garbage collecting) pools would all be
> derived from this type. 

Good ideas, but seems to me (disclaimer: I am not a compiler expert, nor
do I play one on Usenet) it would be quite a challenge for the compiler
to reliably warn of misuse.  Tracking dangerous operations applied
directly to an access type is not hard, but what about unchecked
conversions, address clauses, or other operations modifying or
referencing the objects (or components of the objects) the access type
points to?  In Ada, access types are often used for dynamic data
structures (lists, maps, graphs, stacks, etc.) which often contain
nested access objects.

Re: Ammo-zilla

[Lutz Donnerhacke]

* David Starner wrote:
>If garbage collection is not mandated, however, then it can't be relied on in 
>Ada code that might run under systems that don't garbage collect - i.e. 
>portable Ada code can't use it. Hence either you deallocate any memory 
>yourself, or suffer garbage leaks while running under a non-garbage 
>collecting system.

Almost all memory leaks I came across were caused in an internal handling
routine or in returning a pointer to an object leaving the 'free' procedure
to the user.

Internal routines should define there own access type (and so a seperate
allocation pool) and only use pointers of that type. If the access type
definition goes out of scope, all objects in this pool can be freed without
any need for complex garbage collection. IIUC Ada 95 enforces this.

Returning a pointer to an uplevel scope is bad design. If tagged type are
used (most cases, due to the well known abstract factory pattern), you can
replace your code in almost all cases in the following way:

  package Factories is
    type Factory is private;  
    type Object is tagged private;
    type Object_Ptr is access Object;
    function Make_A_Pointer_To_Object(f: in Factory) return Object_Ptr;
    ...    
  end Factories;

  procedure Do_Something(aFactory: in Factory)
    an_Object_Ptr: Object_Ptr := Make_A_Pointer_To_Object(aFactory);
  begin
    ...
    Free(po);   -- Don't forget it on all possible exits!
  exception
    when others =>
      Free(po); -- Don't forget it on all exceptions!
      raise;    -- Fire again.      
  end Do_Something;

by:
  package Factories is
    type Factory is private;  
    type Object is tagged private;
    function Make_A_Class_Wide_Object(f: in Factory) return Object'Class;
    ...    
  end Factories;

  procedure Do_Something(aFactory: in Factory)
    an_Object: Object'Class := Make_A_Class_Wide_Object(aFactory);
  begin
    ...
  end Do_Something;

In the rare cases where real pointers must be returned to build up a larger
dynamic structure the whole structure should be implemented as a seperate
package providing a Controlled object.

It took me several weeks to determine this. Thanks to the help of the group
regulars. I hope I wrote not so much bullshit.

Re: Ammo-zilla

[Matthew Heaney]

In article <slrn81mia6.uth.lutz@belenus.iks-jena.de> , lutz@iks-jena.de 
(Lutz Donnerhacke) wrote:

> Returning a pointer to an uplevel scope is bad design. If tagged type are
> used (most cases, due to the well known abstract factory pattern), you can
> replace your code in almost all cases in the following way:

[snipped]

>by
>   package Factories is
>     type Factory is private;
>     type Object is tagged private;
>     function Make_A_Class_Wide_Object(f: in Factory) return Object'Class;
>     ...
>   end Factories;
>
>   procedure Do_Something(aFactory: in Factory)
>     an_Object: Object'Class := Make_A_Class_Wide_Object(aFactory);
>   begin
>     ...
>   end Do_Something;


This will work for only trivial cases, because type Object is
nonlimited.  It's *very* common in Ada95 to use access discriminants to
compose abstractions, and this requires a limited type.

In fact, I recommend that for doing class-wide programming, you use a
limited and indefinite type, like this:

package P is

  type T (<>) is abstract limited private;

  type T_Access is access all T'Class;

  <primitive ops takes access params>

  procedure Free (O : in out T_Access);

end P;


package P.C is

  type NT is new T with private;

  function New_NT (...) return T_Access;

  <override primitive ops>

end P.C;


Yes, this returns an access object.  Yes, you have to manually call
Free.  Yes, it's possible to have memory leaks.

But wait!  You can use a smart pointer to do the memory reclamation
automatically, with only a small amount of additional syntactic
overhead.  The modified packages look like this:

package P is

  type T (<>) is abstract limited private;

  type T_Access is access all T'Class;

  <primitive ops takes access params>


   type T_Handle is private;
   -- Implemented as a private derivation from Controlled.

   function "+" (Handle : T_Handle) return T_Access;

end P;


package P.C is

  type NT is new T with private;

  function New_NT (...) return T_Handle;
  -- Constructor now returns a smart pointer, not raw access object.

  <override primitive ops>

end P.C;


I have discussed this issue several times in the Ada95 Design Patterns
list, and there's an article (and several more examples) of how to
implement a smart pointer.

<http://www.acm.org/archives/patterns.html>


> In the rare cases where real pointers must be returned to build up a larger
> dynamic structure the whole structure should be implemented as a seperate
> package providing a Controlled object.

Consider using a smart pointer.


> It took me several weeks to determine this. Thanks to the help of the group
> regulars. I hope I wrote not so much bullshit.

Another resource is the Ada95 Design Patterns mailing list.  You can
subscribe by sending the message (body)

subscribe patterns <your full name>

to the ACM mailing list server.

<mailto:listserv@acm.org>



--
Why stop at evolution and cosmology, though? Let's make sure that the
schoolkids of Kansas get a really first-rate education by loosening up
the teaching standards for other so-called scientific ideas that are,
after all, just theories. The atomic theory, for example. The theory of
relativity. Heck, the Copernican theory--do we really know that the
universe doesn't revolve around the earth?

John Rennie, Scientific American, Oct 1999

Re: Ammo-zilla

[Robert Dewar]

In article <7vadsp$8q61@news.cis.okstate.edu>,
  dvdeug@x8b4e53cd. (David Starner) wrote:
> Under the "as if" rule, C allows garbage collection, and I've
> got a C compiler that compiles targetting the JVM.

Yes, but the C language, unlike Ada, was not designed to
facilitate garbage collection, so it is MUCH tricker to
implement GC in C, especially if you really expect to
accomodate the typical universe of existing C programs.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ammo-zilla

[Charles Hixson]

Laurent Guerby wrote:

> Quite the contrary, garbage collection is allowed (but not mandated)
> by the language (see section 13.11.3 of the Ada 95 RM), and it's of
> course available for Ada compilers targetting the JVM.
>
> --LG

I acknowledge the fact.  This, however, does not make it into a
component of the language.  To get it with the JVM one must take the
JVM.  This does have it's advantages, but it also has disadvantages.
The JVM was designed with Java in mind, and no other language can
reasonably expect to match it as well.  (Even for Java, many folk have
objected sufficiently that some companies have written compilers that
take Java all the way to machine code...a formidable task!)   Also, and
speaking particularlly to the point of garbage collection, I would
prefer a collector that one could invoke as needed, or at least one that
was easy to stop and start.  I believe that the gc calls within Java are
"hints".

Ada and GC (Was Re: Ammo-zilla)

[Vladimir Olensky]

Charles Hixson wrote in message <3818D4F0.92FC4DC9@mail.earthlink.net>...

> Also, and
>speaking particularlly to the point of garbage collection, I would
>prefer a collector that one could invoke as needed, or at least one that
>was easy to stop and start.  I believe that the gc calls within Java are
>"hints".
>


Probably Modula-3 GC (exists for more than 10 years) is  better "hint"
regarding user control over GC.

http://www.research.digital.com/SRC/m3sources/html/runtime/src/common/RTColl
ector.i3.html
http://www.research.digital.com/SRC/m3sources/html/runtime/src/common/RTColl
ectorSRC.i3.html

These references are also available from the  Modula-3 Language definition
page:
http://www.research.digital.com/SRC/m3defn/html/m3.html

There were some concerns  that as GC in Ada is not mandatory
 and it's implementation is up to Ada vendors then using it would
 lead to loosing portability (compiling and using code originally written
 for system with GC on  a system that does not have GC would lead
 to memory leaks).

To avoid such situation  Ada GC could be implemented not within the core
system but as separate package. When it  WITHed with the user program
than it could be invoked for TRACED  ACCESS TYPES.

So on systems without GC that code just could not be compiled and used
without
necessary changes.

In M3  references by default are traced and when one do not want to use GC
with them
they are marked as UNTRACED
(http://www.research.digital.com/SRC/m3defn/html/refs.html)

In Ada references by default are UNTRACED and could be set to TRACED to be
handled by the attached (WITHed) GC. Such approach would provide
compatibility
with the existing  Ada design and facilitate better Ada usage for general
type
applications (not  embedded ,real-time and safety critical where
unpredictable
delays caused by GC are unacceptable).

Regards,
Vladimir Olensky

Re: Ada and GC (Was Re: Ammo-zilla)

[David Botton]

I have found many times that GC can be unacceptable do to unpredictable
delays even on non-embedded, real-time and safety critical systems. Go
explain to a power user of large Java programs why they have to occasionally
wait to regain usable control of the application do to GC crunching. (I
believe this had a part in the demise of Corel's Java Office Suite. Applix
just uses Java like an X terminal and does the real work off site.)

David Botton

Vladimir Olensky wrote in message ...
(not  embedded ,real-time and safety critical where
>unpredictable
>delays caused by GC are unacceptable).

Re: Ada and GC (Was Re: Ammo-zilla)

[Vladimir Olensky]

David Botton wrote in message <7vc3v5$1888$1@news.gate.net>...
>I have found many times that GC can be unacceptable do to unpredictable
>delays even on non-embedded, real-time and safety critical systems. Go
>explain to a power user of large Java programs why they have to
occasionally
>wait to regain usable control of the application do to GC crunching. (I
>believe this had a part in the demise of Corel's Java Office Suite. Applix
>just uses Java like an X terminal and does the real work off site.)



That's why  I wrote that Java GC is not a good "hint" for user controlled GC
and M3 GC is much better in that respect.

My view is that  all objects  by default should be UNTRACED.
Only those objects that are subjected to GC should be marked
as TRACED.  This approach is opposite to what is done in Modula-3
 but it gives  full control to the programmer over GC and it also provides
 compatibility with the current Ada 95 implementations

All the traced objects should be allocated in separate storage pool
controlled
by GC pool storage manager that could provide all needed operations for user
to control GC process.

  I was pleased very much  by  the nice  Tucker Taft post regarding this
issue.
Now  I have a feeling that this issue has grown up and we may expect  some
progress  in this area soon.

Regards,
Vladimir Olensky

Re: Ada and GC (Was Re: Ammo-zilla)

[Samuel T. Harris]

Vladimir Olensky wrote:
> 
> David Botton wrote in message <7vc3v5$1888$1@news.gate.net>...
> >I have found many times that GC can be unacceptable do to unpredictable
> >delays even on non-embedded, real-time and safety critical systems. Go
> >explain to a power user of large Java programs why they have to
> occasionally
> >wait to regain usable control of the application do to GC crunching. (I
> >believe this had a part in the demise of Corel's Java Office Suite. Applix
> >just uses Java like an X terminal and does the real work off site.)
> 
> That's why  I wrote that Java GC is not a good "hint" for user controlled GC
> and M3 GC is much better in that respect.
> 
> My view is that  all objects  by default should be UNTRACED.
> Only those objects that are subjected to GC should be marked
> as TRACED.  This approach is opposite to what is done in Modula-3
>  but it gives  full control to the programmer over GC and it also provides
>  compatibility with the current Ada 95 implementations
> 
> All the traced objects should be allocated in separate storage pool
> controlled
> by GC pool storage manager that could provide all needed operations for user
> to control GC process.

Why not package up this GC as an Ada 95 storage pool and simply
associate
it to the access types which need GC? With the inclusion of the storage
pool
concept in Ada 95, I don't see this "to GC or not to GC" within Ada
itself
as being a _very_ important issue.

> 
>   I was pleased very much  by  the nice  Tucker Taft post regarding this
> issue.
> Now  I have a feeling that this issue has grown up and we may expect  some
> progress  in this area soon.
> 
> Regards,
> Vladimir Olensky

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Scientific and Technical Systems
"If you can make it, We can fake it!"

Re: Ada and GC (Was Re: Ammo-zilla)

[David Botton]

Sounds like a great group project for the Ada community :-)
Perhaps some one should give a crack at starting the project. I'd be happy
to put AdaPower at your service.

David Botton

Samuel T. Harris wrote in message <381B7AA0.65DDACE5@hso.link.com>...

>Why not package up this GC as an Ada 95 storage pool and simply
>associate
>it to the access types which need GC? With the inclusion of the storage
>pool
>concept in Ada 95, I don't see this "to GC or not to GC" within Ada
>itself
>as being a _very_ important issue.

Re: Ammo-zilla

[Robert I. Eachus]

Laurent Guerby wrote:
 
> Quite the contrary, garbage collection is allowed (but not mandated)
> by the language (see section 13.11.3 of the Ada 95 RM), and it's of
> course available for Ada compilers targetting the JVM.

    Actually there are some types for which it is mandated:

"Implementation Requirements

"No storage associated with an Unbounded_String object shall be lost
upon assignment or scope exit."  RM A.4.5(88)

    And those for which it is not recommended:

"Implementation Advice

"Bounded string objects should not be implemented by implicit pointers
and dynamic allocation."

    However I think that one of the easiest and most needed language
extensions is to have storage pools with reference counting and with
garbage collection predefined.  (Probably as generic children of
Ada.Finalization.)  The first is easily written in a portable manner,
but doing GC right for arbitrary types requires compiler
support/modifications.  (There are various methods, but all require that
access values for that storage pool contain more than a simple
pointer.)  You can create a storage pool with garbage collection
semantics without compiler support, but it requires discipline on the
part of the programmer.  (For example, you create a handle type, and
objects designated by handles are treated as referenced during GC, while
pointers and 'Access do not cause an object to be recognized as in use.)
-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ammo-zilla

[Robert Dewar]

In article <38189268.43EB150F@mail.earthlink.net>,
  Charles Hixson <charleshixsn@mail.earthlink.net> wrote:
> I am continually attracted to Ada, however:
> The Ada approach to memory management reminds me of the PL/1
> approach, only simplified a bit.

I suspect you don't remember PL/1 storage management that well,
because the comparison is inappropriate. PL/1 expected to have
manual storage allocation, and the design was focussed in that
area, and PL/1 is better than either Ada or C++ from this point
of view, in particular with respect to the AREA management
facilities.

Yet another instance of the general rule

"PL/1 is not as bad as people think it is"

:-)

> I suppose that you can say that it's better than
> C++, but that's *REALLY* faint praise.  There are a lot of
> details that I don't fully understand, but this is one of
> Ada's weaker aspects.

Clearly you don't fully understand it if you say:

> e.g., garbage collection is eliminated from the language.

which of course is quite bogus. Indeed the design of Ada very
much assumed that garbage collection would be implemented, and
the design specifically allows for this. One of the reasons
that Unchecked_Deallocation has the status it does is that
the designers expected that GC would be generally used.

Of course the language design does not REQUIRE garbage
collection, and indeed it is rather hard to require this
in a formal definition, because it is not really part of
the formal semantics (storage allocation is part of the
implementation semantics, not the language semantics).
Basically a language "requires" GC by not providing any
other alternative for manual deallocation (as in Algol-68).

The issue of GC was most certainly discussed during the
Ada 95 design. I tried indeed to insert a statement into
the information systems annex saying that GC was required
for that annex, but I got precisely ZERO support from
anyone else even for that minor step.

The issue in requiring GC is whether indeed it is practical to
require GC in a language that is intended to be used in very
high efficiency compiled environments, and in embedded realtime
environments (remember that the two general purpose languages
to have embraced GC, Algol-68 and Java, have not created a
track record here, Java has yet to prove itself in these two
respects).

As to why GC has not in fact been implemented in the Ada world,
with the exception of JVM based systems like GNAT-for-Java, the
answer is very simple: lack of demand. For example at Ada Core
Technologies, we get many customers wanting many enhancements,
but GC has never shown up on the radar screen even as a minor
pip in this set of requests.

>  The second is the syntax used in "object" declaration.  Very
> clumsy.

Well anyone can find anything clumsy, but I must say this is
very odd, why you would think that:

   x : int;

is any less clumsy than

   int x;

is peculiar to me! But perhaps you have your terminology wrong
and don't really mean object declaration at all????

> Now I *do* understand that the reason for this approach

Actually, as described above, you don't understand the reason
for the design here, which is to be completely neutral on
GC, and leave it as something that the implementation will
provide if it is useful to do so.

> I feel relativly certain that if the
> language were to be designed today that many things would have
> been done differently.

You may feel certain, but in fact I think VERY little has
changed that would have resulted in a change in design. The
one area I can think of is the "with type". Indeed the ARG is
now discussing possible language extensions, and what is
interesting about this is that these are relatively few
significant suggestions on the table.

Certainly in the case of garbage collection there is nothing
at all to discuss. No one in their right mind is proposing
*removing* unchecked deallocation from the language, so the
only issue is whether implementors will provide GC. The answer
to that is simple, they will provide it if they see potential
customers who want it enough to make the effort worth while.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ammo-zilla

[Aidan Skinner]

On Sun, 24 Oct 1999 12:19:26 GMT, Robert Dewar
<robert_dewar@my-deja.com> wrote: 

>Now that's an interesting comment, because to me C++ and Ada
>are identical in this particular department, can you explain
>why you think Ada is better wrt memory leaks?

<disclaimer: I don't know C++ terribly well, far worse than I know Ada
or Pascal or C>

I think it's probably a personal issue, and one of style more than
anything else.

In C++ I tend to use {pointers|access} types somewhat heavily, in
Ada it's very rare that I do so. I'm also a huge fan of Controlled types in
Ada, I really like the way that they work and use them extensively, I
find the use of Finalize etc to be more intuitive than overloading ->
(this is *definately* a style thing, I know).

I also find it far easier to be disciplined in my code general with
Ada than with C++, although that is almost certainly a style thing (I
have similar problems with Java but not as badly, I think it's the
syntax[1]). 

YMMV etc.

- Aidan

[1] I grew up with Pascal[2], I don't like the way that C like
languages look...

[2] And Sinclair Spectrum BASIC
-- 
"I say we just bury him and eat dessert"
http://www.skinner.demon.co.uk/aidan/

Re: Ammo-zilla

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

Food for thoughts:

Aidan Skinner <aidan@skinner.demon.co.uk> a �crit dans le message :
slrn816t73.114.aidan@skinner.demon.co.uk...
> I also find it far easier to be disciplined in my code general with
> Ada than with C++, although that is almost certainly a style thing (I
> have similar problems with Java but not as badly, I think it's the
> syntax[1]).
>
Or maybe, people who are naturally disciplined in their thinking habits feel
more at ease with Ada than C++ ....
--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: Ammo-zilla

[Matthew Heaney]

In article <7uutgd$87h$1@nnrp1.deja.com> , Robert Dewar 
<robert_dewar@my-deja.com>  wrote:

>> that there's a lot of memory leaks in it, which Ada is a lot better for.
>
>
> Now that's an interesting comment, because to me C++ and Ada
> are identical in this particular department, can you explain
> why you think Ada is better wrt memory leaks?


I can't speak for the original poster, but perhaps one reason is that
functions in Ada can return unconstrained array types, eliminating the
need to heap use, and therefore eliminating a source of memory leaks.

I agree with Robert, but I'd go further and say that here C++ is
superior to Ada95, because you can implement true "smart pointers" (by
overriding the dereference operator "->") that reclaim memory
automatically.

You can do something very similar in Ada95 though, by wrapping the raw
access object in a Controlled type and using unary plus to return the
value.  For example:

  type Bool_Exp is abstract tagged limited private;

  type Bool_Exp_Access is access all Bool_Exp'Class;

  -- Here's the smart pointer type:
  type Exp_Handle is private;

  function "+" (Handle : Exp_Handle) return Bool_Exp_Access;


The article "Smart Pointers", in the patterns archive, describes the
technique.

<http://www.acm.org/archives/patterns.html>

(Use the search engine for find the word "smart" in the subject line.)


Perhaps in a future version of the language controlled-ness (or some
other form of garbage collection) can be applied to access types
directly.  For now, the smart pointer idiom isn't too much pain.

Re: Ammo-zilla

[Robert Dewar]

In article <38120FAF.945ADD7D@hso.link.com>,
  "Stanley R. Allen" <s_allen@hso.link.com> wrote:
>
> If anyone out there is struggling with their organization to
retain
> (or introduce) Ada as an alternative to C++, consider this:
>
>     http://www.mozilla.org/hacking/portable-cpp.html
>
> Imagine what Ada's detractors would be saying if writing
portable
> Ada code was as restrictive as writing C++ code is these days!

Don't use templates!!! A pretty amazing rule, note that it
implies, don't use the STL. Of course part of this list just
reflects the fact that C++ compilers are WAY behind Ada
compilers in conforming to the standard, standard conformance
just doesn't seem a very high priority in the C++ world.

Still I agree, this is a VERY nice reference (definitely
something to add to adapower :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ammo-zilla

[David Botton]

Added at http://www.adapower.com/articles

David Botton

> Still I agree, this is a VERY nice reference (definitely
> something to add to adapower :-)