> On 2011-07-10 11:29:38, Ali Saidi wrote: > > src/cpu/o3/lsq_unit.hh, line 584 > > <http://reviews.m5sim.org/r/502/diff/3/?file=13288#file13288line584> > > > > Where does this get freed? > > Gabe Black wrote: > In the dynInst destructor. This is what's done for regular loads and > stores too. It has to belong to the instruction and not an individual access > since the same memory may be filled by two accesses and can't be freed in two > pieces. I definitely agree that it wasn't straightforward finding where it > gets deleted.
You were on track asking about a memory leak, though. I turns out this patch was leaking sender state objects, and because those have a DynInstPtr to the instruction they go with, those were building up and eventually pushed O3 past its limit. This would happen after about 1500 stores to memory mapped registers, so not for a long time. I think I was also leaking packets and request objects. A new version will be uploaded once I've done a little more testing. - Gabe ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/502/#review1399 ----------------------------------------------------------- On 2011-07-03 03:36:00, Gabe Black wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/502/ > ----------------------------------------------------------- > > (Updated 2011-07-03 03:36:00) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > ------- > > O3: Implement memory mapped IPRs for O3. > > > Diffs > ----- > > src/cpu/o3/lsq_unit.hh 1b4b9c05ad2b > src/cpu/o3/lsq_unit_impl.hh 1b4b9c05ad2b > > Diff: http://reviews.m5sim.org/r/502/diff > > > Testing > ------- > > > Thanks, > > Gabe > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
