|garbage collection firstname.lastname@example.org (Lex Spoon) (2003-07-13)|
|Garbage collection email@example.com (2004-07-28)|
|Re: Garbage collection firstname.lastname@example.org (2004-08-04)|
|Re: Garbage collection email@example.com (Sebastian) (2004-08-04)|
|Re: Garbage collection firstname.lastname@example.org (2004-08-05)|
|Re: Garbage collection email@example.com (Basile Starynkevitch \[news\]) (2004-08-05)|
|Re: Garbage collection firstname.lastname@example.org (Nick Roberts) (2004-08-09)|
|Re: Garbage collection email@example.com (2004-08-10)|
|Re: Garbage collection firstname.lastname@example.org (glen herrmannsfeldt) (2004-08-11)|
|Re: Garbage collection email@example.com (Nick Roberts) (2004-08-13)|
|Re: Garbage collection firstname.lastname@example.org (Tomasz Zielonka) (2004-08-13)|
|Re: Garbage collection email@example.com (Antti-Juhani Kaijanaho) (2004-08-15)|
|Re: Garbage collection firstname.lastname@example.org (glen herrmannsfeldt) (2004-08-15)|
|Re: Garbage collection email@example.com (Nick Roberts) (2004-08-23)|
|[11 later articles]|
|Date:||10 Aug 2004 17:32:25 -0400|
|Organization:||AOL Bertelsmann Online GmbH & Co. KG http://www.germany.aol.com|
|Posted-Date:||10 Aug 2004 17:32:25 EDT|
"Nick Roberts" <firstname.lastname@example.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?
Return to the
Search the comp.compilers archives again.