Re: Garbage collection

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


> 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.


As I understand it, they all have such a cache, except for certain
early steppings of the original Pentium. When it was discovered that
the omission of the cache had a disasterous effects on the execution
speed of some legacy (mostly 16-bit) software, Intel were quick to put
the cache back into their later models.


The Intel models have a cache of 96 extended descriptors, and the
AMD models have 128 I think.


To be honest, I'm not quite sure how the discussion got onto
segmentation in this thread, but never mind :-)


>> 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.


I don't understand why it is necessary for the PTEs to be set to
point to any frame. Why not just set the P bit to 0?


> 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.


An interesting test, but not really a fair test of a machine's
speed, since it is somewhat unrepresentative of real workloads.


--
Nick Roberts

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