| Analysis | The 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. |