`mps_arena_step` with a multiplier of `0.0` misbehaves due to integer overflow

[pipcet]

Calling mps_arena_step with a multiplier of 0 and a nonzero interval results in an unsigned overflow and unintended full collections, at least when Clock is an unsigned type, as it is here.

      if (PolicyShouldCollectWorld(arena, (double)(availableEnd - now), now,
                                   clocks_per_sec))
      {

in global.c results in this, in some cases: if the loop runs more than once, it is possible for availableEnd to be the original now, now to be the new now (thus greater), but still less than intervalEnd. This results in (double)(availableEnd - now) to be a very large number when it should actually be less than 0.

I thought this was a case of pilot error and not worth reporting, but the documentation recommends the multiplier of 0.0 in its proposed event loop.

TBH, it's not entirely clear to me what the precise semantics of the multiplier and interval parameters are, even after reading the documentation. I suspect that in the Emacs case, we would prefer no opportunistic full collections to be started, which would require passing 0.0 as multiplier and fixing the code, I think.

[ellerh]

I think the expression (availableEnd - now) never overflows because the invariant now <= intervalEnd <= availableEnd holds:

• The intervalEnd <= availableEnd part is true because interval and multipler are non-negative.
• The now < intervalEnd part is the termination condition of the while loop.

The problem is more likely issue #308.

[pipcet]

I think the expression (availableEnd - now) never overflows because the invariant now <= intervalEnd <= availableEnd holds:

It does not, as I've described above.

* The `intervalEnd <= availableEnd` part is true because `interval` and `multipler` are non-negative.

No, the multiplier was 0.0 in the proposed code, which resuts in intervalEnd > availableEnd.

The problem is more likely issue #308.

Unlikely.