integration of PolySpace mods into MLton
Alain Deutsch
deutsch@polyspace.com
Tue, 5 Feb 2002 21:56:12 +0100 (MET)
Just a quick answer to some points:
On Tue, 5 Feb 2002, Stephen Weeks wrote:
> * I didn't understand the reason for the test on line 1151 of gc.c
> or (s->toSize >= (128ul*1024ul*1024ul))
> that forces toSpace to be unmapped if it is too small.
If is my understanding that this extra code instead forces the
unmapping of the old space if it is too large, not too small. I
added this code in order to improve the VM behaviour of the system
when paging. Assume that fromSpace+toSpace > RAMsize, we are
swapping or rather paging. At the end of the GC cycle the old
space contains dirty pages that are useless but that the OS will
at high cost preserve their contents by paging them out to disk.
The OS does not know these pages current contents will never be
read again. Unmapping them is a way of letting the OS know that we
will not need them anymore.
> * Do you need the ability set RAMslop from the command line? We have
> it at .85, but you have it at .9.
Preferably, as we tend to have very large memory footprints.
>
> * Do you still need -stop s when compiling -native false? We had
> eliminated it.
As long as we can compile and link in other C files, this is OK.
>
> * Do you need the -O option when compiling -native false? We had
> eliminated it
We need to be able to set the optimisation level.
> * I assume your checkframes.sh script was handling the MLton bug in
> the calculation of maxFrameSize that we fixed on 2000-10-17.
Precisely.
Alain.
--
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