From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,b99897135d6631cc X-Google-Attributes: gid103376,public Path: g2news1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed.mathworks.com!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.multikabel.nl!news2.euro.net!216.196.110.149.MISMATCH!border2.nntp.ams.giganews.com!nntp.giganews.com!news.cambrium.nl!news.cambrium.nl!humbolt.nl.linux.org!news.nl.linux.org!news.wind.surfnet.nl!surfnet.nl!news-stob.telia.net!telia.net!217.209.241.173.MISMATCH!masternews.telia.net.!newsc.telia.net.POSTED!not-for-mail From: =?ISO-8859-1?Q?Bj=F6rn_Persson?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 X-Accept-Language: sv, sv-se, sv-fi, en-gb, en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: memory management and productivity References: <40d15023$1_1@baen1673807.greenlnk.net> <40d69121$1_1@baen1673807.greenlnk.net> <40d932fe_1@baen1673807.greenlnk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: Date: Thu, 24 Jun 2004 00:34:18 GMT NNTP-Posting-Host: 217.209.116.179 X-Complaints-To: abuse@telia.com X-Trace: newsc.telia.net 1088037258 217.209.116.179 (Thu, 24 Jun 2004 02:34:18 CEST) NNTP-Posting-Date: Thu, 24 Jun 2004 02:34:18 CEST Organization: Telia Internet Xref: g2news1.google.com comp.lang.ada:1841 Date: 2004-06-24T00:34:18+00:00 List-Id: David Starner wrote: > The only library garbage collectors I know about are conservative; they= > assume that every pointer-size chunk of accessible memory is a pointer,= > (unless it's in a block of data that was allocated with a special funct= ion > that tells the GC there are no pointers in that data.) They don't move > memory because you can't adjust pointers if you can't tell pointers fro= m > integers. A garbage collector that was part of the compiler could tell > integers from pointers (that is, be a precise collector instead of a > conservative collector) and could move items in memory (which many > high-performance GCs do.) This makes easier, for example, for a compile= r > to scan only the new stuff, which has a shorter live time than the stuf= f > the program has kept around for a while. The first may be more importan= t; > a misplaced integer could potentially hold several megabytes of garbage= in > memory. I see. For a language like Ada, something that can't tell a pointer from = an integer clearly isn't as good as it could be. I knew there had to be=20 some drawback with a garbage collector that works for C. :-) --=20 Bj=F6rn Persson PGP key A88682FD omb jor ers @sv ge. r o.b n.p son eri nu