[MLton] callcc and space use

[Matthew Fluet]

On Thu, 21 Feb 2008, Vesa Karvonen wrote:
>>  I sketched out the following as a possible resizing policy, which gives
>>  some more controls while trying to maintain the current behavior of
>>  single-threaded programs:
> [...]
>>          reservedShrink =
>>            (stackReserved <= reservedPermit)
>>            ? stack->reserved
>>            : (size_t)(s->controls.ratios.stackCurrentShrink * stack->used);
>
> I guess the above should use stack->reserved rather than stack->used.

Correct.  Just seeing if anyone was paying attention. ;-)

> Hmm... What about overflows when multiplying with ratios much greater
> than 1.0?  It might make sense to do the computations in floating
> point and only convert the final result to a size_t value.

There's no safety problem: reservedMin is at most a constant (2 * max 
frame size) plus the current stack->used, so, won't overflow (on 32-bit 
systems) unless you have a 4G stack in hand, in which case you've almost 
certainly exhausted memory long before hand.  sizeofStackShrink is 
guaranteed to return a desired reserved size greater than or equal to 
reservedMin and less than or equal to the current stack->reserved.

>>  with the following defaults:
>>
>>    s->controls.ratios.stackCurrentGrow = 2.0;
>>    s->controls.ratios.stackCurrentMaxReserved = 32.0;
>>    s->controls.ratios.stackCurrentPermitReserved = 4.0;
>>    s->controls.ratios.stackCurrentShrink = 0.5;
>>    s->controls.ratios.stackMaxReserved = 8.0;
>>    s->controls.ratios.stackShrink = 0.5;
>>
>>  The difference from the current policy is that both the current and paused
>>  stacks have a maximum reserved size that is a ratio of the used size.
>>  The other difference is that a lot more ratios can be set by runtime
>>  options.
>
> So, if I understand the resizing policy sketch, you can turn off the
> shrinking (beyond the stackMaxReserved limit) just by setting
> stackShrink = 1.0.  Also, setting the MaxReserved ratios high, you can
> get almost the old behavior (just shrinking gradually as if there was
> no limit).

Correct.  And, as you note, one might like to negate the effect of the 
MaxReserved ratios by choosing very large ratios, which would require 
handling overflows in the reservedMax calculation to be handled correctly.