RubyPort: Fix evict/invalidate packet memory leak
Review Request #1813 - Created April 7, 2013 and submitted
| Information | |
|---|---|
| Joel Hestness | |
| gem5 | |
| default | |
| Reviewers | |
| Default | |
Changeset 9630:2ea801a03fa5 --------------------------- RubyPort: Fix evict/invalidate packet memory leak When using the o3 or inorder CPUs with many Ruby protocols, the caches may need to forward invalidations to the CPUs. The RubyPort was instantiating a packet to be sent to the CPUs to signal the eviction, but the packets were not being freed by the CPUs. Consistent with the classic memory model, stack allocate the packet and heap allocate the request so on ruby_eviction_callback() completion, the packet deconstructor is called, and deletes the request (*Note: stack allocating the request causes double deletion, since it will be deleted in the packet destructor). This results in the least memory allocations without memory errors.
Long runs with Valgrind and verified that the Ruby transitions that caused these memory leaks were exercised. Multithreaded benchmarks with elevated contention witness huge memory consumption decreases.
Ship It!
Ship It!
Posted (April 8, 2013, 1:11 a.m.)
-
src/mem/ruby/system/RubyPort.cc (Diff revision 1) -
Could you add a comment that the request does not need a response and is thus deleted with the packet. Also, it would be good to highlight that the same packet (potentially altered) is now sent to all the ports and this is making assumptions about what they do (or don't do) to it. Thanks