Re: Garbage collection

Nick Roberts wrote:
> On 4 Aug 2004 02:45:19 -0400, Sebastian <sk@z.pl> 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
this:


http://www.hpl.hp.com/personal/Hans_Boehm/gc/complexity.html


rgds


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

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