MPS issue job003455

TitleFrequent ramps can mess up the ramping algorithm and cause performance problems
Assigned userNick Barnes
DescriptionThe MPS provides a "ramping" API to the client. Inspection of the code suggests that if ramps are entered often enough then the ramp strategy may break, preventing promotion of ramp-surviving objects and causing performance problems.
AnalysisThe ramp state machine (design.poolamc.ramp) is supposed to ensure that after a non-trivial ramp (a ramp during which the ramp generation has been collected to itself at least once), the ramp generation is collected at least once while promoting to the after-ramp generation. It seems to me [NB 2013-04-04] that this might not be the case: if we are in the FINISH state and start a collection of the ramp generation, putting us into the COLLECTING state, and enter a ramp while in the COLLECTING state, then we will go directly to the BEGIN state, and may be able to transition to the RAMPING state (changing the ramp generation to forward to itself) during the same trace condemnation phase (because the FINISH->COLLECTING and BEGIN->RAMPING transitions both take place during the per-segment operation of AMCWhiten, which may happen many times during a trace condemnation). For this to happen might require condemnations of AMC segments to be interleaved with other operations, but the AMC implementation of ramping should not rely on whether or not that is possible (is it always true that all condemnation for a trace is done atomically with regard to client operations? If so, we should AVER it). The right fix is (I think) to tell pool generations when they are condemned, rather than piggybacking per-generation behaviour (switching the ramp forwarding) into a per-segment method (AMCWhiten). This fix would probably also apply to the use of the AMCReclaim method to transition from COLLECTING to OUTSIDE.
How foundinspection
Observed in1.110.0
Created byNick Barnes
Created on2013-04-04 15:47:42
Last modified byNick Barnes
Last modified on2013-04-04 15:47:42
History2013-04-04 NB Created.