Re: Garbage collection

  "Nick Roberts" <nick.roberts@acm.org> schreibt:


>I wonder if actually the idea is to allocate blocks greater than a
>certain size page-aligned (in a different heap), so that they can be
>moved by page table manipulation?


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.


There may exist similar reasons for using different GC allocation
models, perhaps with regards to new I64 (dis)advantages, but I admit
that a general "too slow" argument is a too vague explication.


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?


DoDi

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