Re: [MLton] tuning up mlton gc

Hello,

On 7/23/14 4:54 PM, Matthew Fluet wrote:
> ...
> In any case, the collection of runtime controls and their effects are
> fairly complicated.  It would be very nice to review, rationalize, and
> refactor the various controls.

Many thanks for the clarifications. Indeed, though the gc architecture
is clear, the many options makes hard to trace the effects of
changing one ...


>
>> 2. Are there some way other than playing with ratios (which could
>> have some undesired effects as well) to have mlton always use
>> generational gc ? ...
> ...  I think that adjusting
> copy-generational-ratio is the simplest and safest solution.
>

Quite effective, and improving gc times a little further. Thanks for the 
hint !

Since we are talking gc, I take the opportunity to mention another
gripe with it :-) :

Another "feature" of model checking is that it eats a lot of space.
In my experience, and whatever the OS and gc options (other than
may-page-heap) mlton rarely suceeds in using more than approximately
half the available RAM, even when the applications would benefit from
more. This obviously makes gc more expensive and, worse, prevents
some applications to complete by lack of memory (while almost half
of RAM is unused).

I understand this follows from the heap growing strategy; this
has been discussed on the list some years ago. But an average
50% efficiency in storage management is quite frustrating, and
certainly not a good point for our tools :-(

On Thu, 19 Aug 2008, Matthew Fluet wrote on the mlton list:

> The second thought is that I wonder if the heap would be easier to
> predict/control if we used one contiguous heap at all times (that is, even
> for major copying collections).  In particular, it would be nice to have
> the behavior described above for fixed-heap --- namely, that one could use
> fixed-heap to grab a large block of memory at the beginning of the program
> and there would be no subsequent resizing, even if the runtime switched
> over from major copying collections to major mark-compact collections.

That would help I guess. A contiguous heap should ease resizing
it in place, and a fixed-heap working that way would be great.

Many thanks again,
     Bernard.

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds

_______________________________________________
MLton-devel mailing list
[email protected]; [email protected]
https://lists.sourceforge.net/lists/listinfo/mlton-devel