TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Proportional Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mime-Version: 1.0
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
From: "S. Ron Oliver" <[log in to unmask]>
Date: Tue, 21 Aug 2001 07:55:23 -0600
In-Reply-To: <[log in to unmask]>
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: "S. Ron Oliver" <[log in to unmask]>
Parts/Attachments: text/plain (41 lines)
At 11:50 AM 8/20/01 -0400, Mark Lundquist wrote:

>In the software industry overall, garbage collection is high on the "must
>have" list for an implementation language. . . . .  etc., etc., etc.

WHEW!

That was quite a dissertation!

But very well thought out.

Just my two cents worth, from the days, MANY years ago, when I did a lot of
work with compilers.

There really are two issues here:

         1.      Garbage Collection, meaning to reclaim memory, say in the
heap, to make
                 it available for new elements.

         2.      Memory (Heap) Fragmentation.

1. tends not to be a performance issue, even in most hard real time
systems.  Compaction algorithms to recover from 2., and when they are
executed, are usually the real performance issues.  Although I have not
looked at a Garbage Collection algorithm (in the larger sense, involving
both 1 and 2), for any compiler recently, I'm guessing that part of the
problem with contemporary C-class compiler writers is they use simplistic
algorithms, and don't particularly care to distinguish between 1 and 2.

Does anyone know for sure?

sro

S. Ron Oliver, semi-retired professor of Computer Science and Computer
Engineering.  www.csc.calpoly.edu/~sroliver

caress Corporation is proud to be the U.S. representative for Top Graph'X,
developers of high quality software components, using Ada.  For more
information, check out www.topgraphx.com.

ATOM RSS1 RSS2