GC is Not Sufficient (Re: Avoiding the second historic mistake) 
Author Message
 GC is Not Sufficient (Re: Avoiding the second historic mistake)

Quote:

> >   Perhaps you don't see the advantages of GC.  So tell me, what
> >   advantages are there to a _lack_ of GC?

Everyone can see the advantages of GC. The advantage of GC is an
advantage only when it is suitable. It becomes a disadvantage
when a language enforces its use no matter how it fits or not.
There are lots of things that cannot be garbage collected. See
below.

Quote:

> In applications that require hard real time predictability,
> GC can be a serious liability.  In systems which do not
> have such a requirement, GC can be a serious advantage.

In a hard real-time and small system, even dynamic memory
allocation is restricted. Static memory allocation will be
used as much as possible. If a language enforces people to
use dynamic memory allocation for all user-defined objects,
this language is definitely not suitable for this kind of
applications.

Quote:
> GC is a tool, it is not nirvana.  In many ways it is unfortunate
> that Java does not also allow manual memory management.  However,
> I understand, and agree with, the security issues that constrained
> the language designers.

Granted. GC is only one of the many ways to handle object
references. There are many situitions that GC cannot handle.
Examples are persistent objects and newtwork objects, they
cannot be garbage collected when they are not in use.

Even for the security or safety issue, it is not suitable
for a langugae to provide only GC for objects allocated in
dynamic memory. A language should enable other safe object
reference protocols, so that programmers will not worry
about to close a newtork connection, to release an operating
system resource, or to yield the control of an persistent
object.

Transframe is the only langugae that provides a generic
object reference protocol that enables various kinds of
object references for different applications.

David Shang



Mon, 01 Nov 1999 03:00:00 GMT  
 GC is Not Sufficient (Re: Avoiding the second historic mistake)

<snip>

Quote:
>In a hard real-time and small system, even dynamic memory
>allocation is restricted. Static memory allocation will be
>used as much as possible. If a language enforces people to
>use dynamic memory allocation for all user-defined objects,
>this language is definitely not suitable for this kind of
>applications.

Although I'm on your side of the general argument, it's only fair to
point out that if you pre-allocate objects before you get to the
real-time parts then whether or not a language has garbage collection
makes no difference.


Mon, 01 Nov 1999 03:00:00 GMT  
 GC is Not Sufficient (Re: Avoiding the second historic mistake)

Quote:

> Although I'm on your side of the general argument, it's only fair to
> point out that if you pre-allocate objects before you get to the
> real-time parts then whether or not a language has garbage collection
> makes no difference.

If you can guarantee that the runtime isn't going to create objects
"behind the scenes", which could cause the collector to run...

-Patrick Bridges

--

***                #include <std/disclaimer.h>                   ***



Mon, 01 Nov 1999 03:00:00 GMT  
 GC is Not Sufficient (Re: Avoiding the second historic mistake)


Quote:

>> Although I'm on your side of the general argument, it's only fair to
>> point out that if you pre-allocate objects before you get to the
>> real-time parts then whether or not a language has garbage collection
>> makes no difference.

Except code size.  If the real-time program is intended to run on
an embedded platform with limited memory map, getting rid of the GC
may spell the difference between using Eiffel and having to go with
C/C++.

There is of course the problem of a runtime library.  

So far as I know, the only Eiffel possibility here is SmallEiffel,
which uses no proprietary runtime library.  And it doesn't have GC
(unless you bolt on BDW) anyway ...

Quote:
>If you can guarantee that the runtime isn't going to create objects
>"behind the scenes", which could cause the collector to run...

Aside from knowing well the libraries you use, there's also the
possibility of grepping the generated C, or for that matter, the
symbol table from the final object, for calls to known allocation
routines.  If you can account for all of these, you may need
not fear behind-the-scenes allocation.

--
Dan Wilder



Tue, 02 Nov 1999 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Avoiding the second historic mistake

2. Avoiding the second historic mistake

3. Avoiding the second historic mistake (And a PROPOSAL!)

4. Terseness [Was Re: Avoiding the second historic mistake]

5. = Avoiding the second historic mistake

6. An Industry Experience (was Avoiding the second historic mistake)

7. Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

8. The great Java showcase (re: 2nd historic mistake)

9. The great Java showcase (re: 2nd historic mistake)

10. The great Java showcase (re: 2nd historic mistake)

11. The great Java showcase (re: 2nd historic mistake)

12. Precision of Floating Point Numbers (Was: Second historic...)

 

 
Powered by phpBB® Forum Software