Re: Garbage collection

On 23 Aug 2004 12:07:39 -0400, Sebastian <sk@z.pl> wrote:


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


Yes, but if you don't move large blocks at all, are you not in danger
of ending up with a lot of (large) unfilled holes?


I should point out that there are two kinds of problem with holes: (a)
running out of actual memory; (b) running out of (logical) address
space. I think it is (b) that is the problem with large holes.


> The main advantage of compacting collector is IMHO extremely fast
> allocation


Hmmm. Well, that may be an advantage, but isn't the /main/ advantage
of a compacting collector the fact that it removes holes? Again, the
problem with these holes may be running out of address space, rather
than running out of actual memory, but it could be both.


> -- but in case of large objects (>=16KB in this case) the more
> complex allocation from non compactable heap is neglibile in
> comparison to object initialisation cost. And then moving such large
> object every time it's generation goes through collection is simply
> huge and unneded cost.


Well, yes, the cost would be huge if you used REP MOVSD on the data
itself. I'm suggesting that if you allocate large blocks page aligned,
you can move them quite quickly by REP MOVSDing in the page tables
instead.


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


I haven't had a lot of experience with .NET, but when I have run one
or two .NET programs (on my 2.4 GHz Celeron 512 MiB Windows XP) they
seem to have run surprisingly slowly. But that's just a bare
observation; I don't know /why/ they were so slow.


> 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


But the criticisms made in this paper (of collection) are based on a
set of assumptions that Microsoft could not make for all the software
running under Windows. They could not simply assume that the only
software requiring garbage collection would be "single-threaded with
moderately long-lived objects".


I know for a fact that they specifically considered the needs of
languages such as LISP, Prolog, and Smalltalk when designing the
original Win16 API. Ironically, the provisions made by Win16 tended
not to be used, because typical LISP, Prolog, Smalltalk, and similar
systems were generally ported from (flat) Unix C, compelling their
own internal provisions to be written. Come 32-bit (flat) Windows,
these internal provisions were sufficient.


--
Nick Roberts

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