Re: Garbage collection

vbdis@aol.com (VBDis)
10 Aug 2004 17:32:25 -0400

          From comp.compilers

Related articles
garbage collection lex@cc.gatech.edu (Lex Spoon) (2003-07-13)
Garbage collection wmccabe@hotmail.com (2004-07-28)
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)
[11 later articles]
| List of all articles for this month |

From: vbdis@aol.com (VBDis)
Newsgroups: comp.compilers
Date: 10 Aug 2004 17:32:25 -0400
Organization: AOL Bertelsmann Online GmbH & Co. KG http://www.germany.aol.com
References: 04-08-032
Keywords: GC
Posted-Date: 10 Aug 2004 17:32:25 EDT

  "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


Post a followup to this message

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