3 ms·

> Your runtime simply needs to bound the amount of reclamation work done at any given time. Wouldn't this transform the problem into a "no more predictable ma

• naasking 10y ago
  Possibly, but maximum memory usage is rarely predictable anyway. I expect it might be even less predictable than maximum latency. However, it may still be possible to conservatively bound your maximum memory usage too, as long as your reclamation-work phase keeps up with your program's allocation rate, then you achieve a steady-state. Suppose some amount of reclamation is done on malloc(), a tunable parameter could measure the ratio of allocation speed of the running program and amount of unreclaimed garbage. This ratio would control how much reclamation work to do before returning from malloc() so you can fall into steady-state.
  • lmm 10y ago
    > Possibly, but maximum memory usage is rarely predictable anyway. I expect it might be even less predictable than maximum latency. Well, if you don't need a bound on memory usage you can just never deallocate. > Suppose some amount of reclamation is done on malloc(), a tunable parameter could measure the ratio of allocation speed of the running program and amount of unreclaimed garbage. This ratio would control how much reclamation work to do before returning from malloc() so you can fall into steady-state. Sure, but that doesn't guarantee anything about what your maximum spikes are going to be. You can have a firm bound on memory consumption or a firm bound on latency, but you can't get both without doing some serious application-specific work.