mem: Unify delayed packet deletion

This patch unifies how we deal with delayed packet deletion, where the
receiving slave is responsible for deleting the packet, but the
sending agent (e.g. a cache) is still relying on the pointer until the
call to sendTimingReq completes. Previously we used a mix of a
deletion vector and a construct using unique_ptr. With this patch we
ensure all slaves use the latter approach.

1 files changed, 2 insertions, 8 deletions

diff --git a/src/mem/dram_ctrl.cc b/src/mem/dram_ctrl.cc
index 3ba4616f7..4bd83f761 100644
--- a/src/mem/dram_ctrl.cc
+++ b/src/mem/dram_ctrl.cc
@@ -586,12 +586,6 @@ DRAMCtrl::printQs() const {
 bool
 DRAMCtrl::recvTimingReq(PacketPtr pkt)
 {
-    /// @todo temporary hack to deal with memory corruption issues until
-    /// 4-phase transactions are complete
-    for (int x = 0; x < pendingDelete.size(); x++)
-        delete pendingDelete[x];
-    pendingDelete.clear();
-
     // This is where we enter from the outside world
     DPRINTF(DRAM, "recvTimingReq: request %s addr %lld size %d\n",
             pkt->cmdString(), pkt->getAddr(), pkt->getSize());
@@ -600,7 +594,7 @@ DRAMCtrl::recvTimingReq(PacketPtr pkt)
     if (pkt->memInhibitAsserted() ||
         pkt->cmd == MemCmd::CleanEvict) {
         DPRINTF(DRAM, "Inhibited packet or clean evict -- Dropping it now\n");
-        pendingDelete.push_back(pkt);
+        pendingDelete.reset(pkt);
         return true;
     }
 
@@ -872,7 +866,7 @@ DRAMCtrl::accessAndRespond(PacketPtr pkt, Tick static_latency)
     } else {
         // @todo the packet is going to be deleted, and the DRAMPacket
         // is still having a pointer to it
-        pendingDelete.push_back(pkt);
+        pendingDelete.reset(pkt);
     }
 
     DPRINTF(DRAM, "Done\n");