[MLton-devel] Stop-and-copy / mark-compact switch criterion

[Alain Deutsch]

On Fri, 16 Aug 2002, Stephen Weeks wrote:

> I did this because of the generational GC.  My thinking is that when
> heap size >2/3 ram size that we want to avoid major gcs as much as
> possible.  Minor gcs in this situation shouldn't page, because they
> only touch the nursery and some of the old generation.  By giving a
> ratio of 1.5, this lets us do more minor gcs per major gc, which I
> hope is a win.

Perhaps you could make some of the constants externally adjustable
so as to provide for command-line tuning (such as this 1.5 factor)
?

Another point I wanted to share: in the GC there are several
decisions made by estimating the live set of the next GC as
plainly the current live set. I think that the CAML gc uses some
form of linear estimator that is based not only on the current
live set but also on the previous ones. I do not know what is the
precision of such improved estimations or the level of benefits
they provide.

Last questions:

Do you allocate large enough objects directly outside the nursery
?

How do you choose the nursery size ? Is the L2 cache size a good
size ?

--
Alain Deutsch, CTO              tel.: +33 (0)1 49 65 32 64
PolySpace Technologies          fax.: +33 (0)1 49 65 05 77
mailto:deutsch@POLYSPACE.COM    http://www.polyspace.com



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel