Steve Reinhardt wrote: > On Fri, Mar 26, 2010 at 10:32 PM, nathan binkert <[email protected]> wrote: > >>> #1 sounds pretty good to me... 2 & 3 seem like overkill. I don't >>> think the overhead of the null pointer is that bad. >>> >> Ok, cool. I'll cook up a diff. >> >> >>>> I'm partial to doing 1, 3, or nothing (in that order.) With #1, we >>>> could also add a feature that requires the senderState to be popped at >>>> every level and where we assert in the Packet destructor that >>>> senderState is NULL. This would ensure that you're not attaching >>>> things to sender state and forgetting about them (causing either a >>>> memory leak, or a programming error because you forgot to do >>>> something.) >>>> >> What about this feature where we ensure that senderState is NULL when >> we call the destructor. Think that's worth trying? I could give that >> a shot and see what happens. Any reason not to do this? (The >> alternative is to try to delete the chain of sender state objects.) >> Seems that one way or another we should try to avoid the memory leak. >> > > That seems reasonable to me. You could always just put a warn() in if > it's non-null and see if you hit it. > > Steve > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > What about one way packets that don't collapse back to the sender? Do we have any of those? Or do we always collapse back at least with the ack?
Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
