Re: Garbage collection

glen herrmannsfeldt <gah@ugcs.caltech.edu>
11 Aug 2004 12:58:25 -0400

          From comp.compilers

Related articles
[2 earlier articles]
Re: Garbage collection nmm1@cus.cam.ac.uk (2004-08-04)
Re: Garbage collection sk@z.pl (Sebastian) (2004-08-04)
Re: Garbage collection tmk@netvision.net.il (2004-08-05)
Re: Garbage collection basile-news@starynkevitch.net (Basile Starynkevitch \[news\]) (2004-08-05)
Re: Garbage collection nick.roberts@acm.org (Nick Roberts) (2004-08-09)
Re: Garbage collection vbdis@aol.com (2004-08-10)
Re: Garbage collection gah@ugcs.caltech.edu (glen herrmannsfeldt) (2004-08-11)
Re: Garbage collection nick.roberts@acm.org (Nick Roberts) (2004-08-13)
Re: Garbage collection t.zielonka@zodiac.mimuw.edu.pl (Tomasz Zielonka) (2004-08-13)
Re: Garbage collection antti-juhani@kaijanaho.info (Antti-Juhani Kaijanaho) (2004-08-15)
Re: Garbage collection gah@ugcs.caltech.edu (glen herrmannsfeldt) (2004-08-15)
Re: Garbage collection nick.roberts@acm.org (Nick Roberts) (2004-08-23)
Re: Garbage collection sk@z.pl (Sebastian) (2004-08-23)
[10 later articles]
| List of all articles for this month |

From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.compilers
Date: 11 Aug 2004 12:58:25 -0400
Organization: Comcast Online
References: 04-08-032 04-08-054
Keywords: architecture, GC
Posted-Date: 11 Aug 2004 12:58:25 EDT

VBDis wrote:


(snip)


> The Intel (segmented) memory management technology imposes some
> penalties on certain operations. Even if the idea of segment registers
> was appropriate when moving from 16 bit code and 64 KB memory limits
> to bigger memory (8086), but in later hardware generations (80386)
> segment register manipulation and the maintenance of the related
> (task, segment...) tables turned out to be too time expensive. This
> was the time when the page-based flat memory model was "invented", as
> a faster memory management model.


A segment descriptor cache could speed up such segment load
operations. I don't know which, if any, processors had one.
I have been told that some did, but have never seen it in any
Intel or AMD literature.


(snip)


> All in all I agree with your guess about page table manipulation for
> fast block moves. Why move memory around byte by byte, when moving
> bigger entitites (pages) costs about the same time, per entity?


As I understand it, it is common on many systems for the memory
allocation system to fill page tables with pointers to one zero filled
page, and then allocate a real page with the first write operation.
There is a story of someone testing the cache memory characteristics
of a machine with C code like:


int *a,*b,i;
a=malloc(100000000);
b=malloc(100000000);
for(i=0;i<100000000;i++) a[i]=b[i];


It would seem that this would require moving enough data to completely
flush the cache, but it might not.


-- glen


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.