Re: Garbage collection

Sebastian <>
23 Aug 2004 12:07:39 -0400

          From comp.compilers

Related articles
[9 earlier articles]
Re: Garbage collection (Nick Roberts) (2004-08-13)
Re: Garbage collection (Tomasz Zielonka) (2004-08-13)
Re: Garbage collection (Antti-Juhani Kaijanaho) (2004-08-15)
Re: Garbage collection (glen herrmannsfeldt) (2004-08-15)
Re: Garbage collection (Nick Roberts) (2004-08-23)
Re: Garbage collection (Sebastian) (2004-08-23)
Re: Garbage collection (Sebastian) (2004-08-23)
Re: Garbage collection (Nick Roberts) (2004-09-03)
Re: Garbage collection (Sebastian) (2004-09-07)
Re: Garbage collection (2004-09-13)
Re: Garbage Collection (1992-08-09)
Re: Garbage Collection (1992-08-11)
Re: Garbage Collection (1992-08-12)
[3 later articles]
| List of all articles for this month |

From: Sebastian <>
Newsgroups: comp.compilers
Date: 23 Aug 2004 12:07:39 -0400
Organization: in Forma
References: 04-07-085 04-08-011 04-08-032
Keywords: GC
Posted-Date: 23 Aug 2004 12:07:39 EDT

Nick Roberts wrote:
> On 4 Aug 2004 02:45:19 -0400, Sebastian <> wrote:
>> [Microsoft garbage collector]
>> *) it's copying GC for not too large objects (AFAIR less than 16KB),
>> larger objects are allocated from yet another heap and are unmoveable
>> (as moving large obiects to compact memory is too slow)
> Sadly, I feel the need to add a caveat to this (helpfully meant)
> advice, that, whilst it is indeed likely to be enlightening to read
> articles published by Microsoft, it is also necessary to bear in mind
> that past evidence suggests Microsoft is not exactly the fount of all
> computing wisdom. I'm afraid I often find that their documentation is
> enlightening in suggesting to me precisely how /not/ to do it.

There are many different things made by MS from terribly (technically) ugly
& bad to nice and well thought stuff.

> I may add that I am not a knee-jerk Microsoft knocker. I feel there is
> genuine evidence of their widespread technical inexpertise.

I'm far (very far) from loving MS, but there is evidence to the contrary as
well. Just to stay wihtin the topic of this ng, for example their newset
compiler suite seems to be a good one.

> The above technique (taken on its own, as I am not myself familiar
> with Microsoft technologies) seems to be evidence in my case. I find
> it hard to believe that the designers just gave up on moving large
> blocks!

Why it is a bad iadea? I find it perfectly reasonable. Those objects of
course come from another heap, so they don't stand in a way of compaction
of smaller stuff.
The main advantage of compacting collector is IMHO extremely fast allocation
-- but in case of large objects (>=16KB in this case) the more complex
allocation from non compactable heap is neglibile in comparison to object
initiaslisation cost. And then moving such large object every time it's
generation goes through collection is simply huge and unneded cost.

Then add the fact that such objects (in typical imperative language code a
CIL typically runs) are typically not too frequently created (by the sheer
size of them, there must be to too many of them) and often are not short
lived. Hence they survive many many collections. Then add to the fact that
when application with pure-copying GC allocates enough memory that swapping
tricks in you're. Each not moved large object is a few pages not swapped.
Moving them is a waste of time, wipes caches, etc.

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

Why to move those objects at all?

> Anyway, my advice is simply to be cautious about Microsoft's
> technology documents, and I suppose the same advice applies to other
> companies.

Well, as evidence shows that whole .Net thing seems to behave OK. So maybe
those guys are not wrong after all.

BTW, if you'd like to read some quite strong anti-compaction advocacy try


Sebastian Kaliszewski
"Never underestimate the power of human stupidity" -- from Notebooks of L.L.

Post a followup to this message

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