On Wed, 23 Feb 2011 16:37:58 -0800, nathan binkert <[email protected]>
wrote:
Does anyone know why the limit event isn't deleted and instead it
prints "be
nice to actually delete the event here" Why can't we just delete it?
That is my fault. I generally don't like allocating stuff without
deleting it, so I stuck the warn in there. It could be autodeleted,
but we generally don't clean up after ourselves on exit, so
autodelete
events aren't processed on simulator exit. You could take out the
warn and just mark it autodelete and it will then become one of a
zillion objects that are not cleaned up on the heap upon shutdown.
(Which is only an issue if you're using valgrind).
I think actually, we're loosing the memory ever time we call simulate()
so the simulator doesn't actually need to exit even. If you're returning
to python to change something/switch cpus and then simulate again a new
limit event is created each time. I imagine we loose the memory if the
limit_event == se_event or not (does python free it)?
For the case with the hack in it now, wouldn't something like
rescheduling it to the current tick, and setting auto delete (it seems
like there is no method to actually do this though) be better? In the
case of multiple calls to simulate() at least there wouldn't be a lot of
events hanging around. In the case that se_event == limit_event I'm not
sure what we can do (see above about python freeing), although perhaps
having one limit event instead of newing one each call to simulate
(reschedule) might be better.
Ali
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
