TR: [clean-list] Next Heap Size Factor ?

Fabien Todescato f.todescato@larisys.fr
Fri, 24 Nov 2000 17:57:55 +0100


Ho, as the question just pops in my mind :

I have read one or two things about fast generational garbage =
collection,
and it is claimed that generational collectors may be suited to soft
real-time applications.

Does the Clean team envision soft real-time as a possible field of
application of the language, and would a change of the =
garbage-collection
algorithm be required in such a case ?

Thanks again

Fabien TODESCATO

-----Message d'origine-----
De : Fabien Todescato=20
Envoy=E9 : vendredi 24 novembre 2000 17:52
=C0 : 'johnvg@cs.kun.nl'
Objet : RE: [clean-list] Next Heap Size Factor ?


Thanks John,

I got the paper and we'll give a look at it. I asked the question out =
of
pure curiosity, I am just an amateur regarding these questions of =
automatic
memory management.

Best regards, Fabien TODESCATO


-----Message d'origine-----
De : johnvg@cs.kun.nl [mailto:johnvg@cs.kun.nl]
Envoy=E9 : vendredi 24 novembre 2000 17:39
=C0 : Fabien Todescato
Cc : clean-list@cs.kun.nl
Objet : RE: [clean-list] Next Heap Size Factor ?


Fabien Todescato wrote:
>If I am not mistaken, then, the standard garbage collector is a =
two-space
>moving copying garbage-collector.

Yes, but only if the amount of heap in use is smaller than about a =
quarter
of the maximum heap size. If it is larger, a two pass sliding =
compacting
collector is used.

>For my personal information, what about the optional mark-scan garbage
>collector ? I think I have read somewhere that it is a sliding =
compactor,
is
>that indeed the case ?

The optional mark-scan garbage collector initially uses a non copying
mark-scan
collector. It just traverses the heap and marks used areas of the heap =
in a
bit vector. When memory is allocated, this bit vector is scanned to =
find
a (aligned) block of memory of at least 256 bytes.

If the heap becomes too fragmented the two pass sliding compactor =
garbage
collector is used in stead to compact the heap again.

For more information see my paper "Optimising Mark-Scan garbage =
collection"
available from:

http://www.cs.kun.nl/~clean/Research/publications/publications.html

(1995, number 10)

Best regards,

John van Groningen