diff options
author | Nathan Binkert <nate@binkert.org> | 2010-06-10 23:17:06 -0700 |
---|---|---|
committer | Nathan Binkert <nate@binkert.org> | 2010-06-10 23:17:06 -0700 |
commit | bc87fa30d72df7db6265be50b2c39dc218076f9f (patch) | |
tree | 9e27c5ec1bbdbee048f2e91fc450d71f47bdf88d /src/mem/ruby/system/CacheMemory.cc | |
parent | aa7888797032bab49b5f0f637c859740497423d8 (diff) | |
download | gem5-bc87fa30d72df7db6265be50b2c39dc218076f9f.tar.xz |
ruby: get rid of RefCnt and Allocator stuff use base/refcnt.hh
This was somewhat tricky because the RefCnt API was somewhat odd. The
biggest confusion was that the the RefCnt object's constructor that
took a TYPE& cloned the object. I created an explicit virtual clone()
function for things that took advantage of this version of the
constructor. I was conservative and used clone() when I was in doubt
of whether or not it was necessary. I still think that there are
probably too many instances of clone(), but hopefully not too many.
I converted several instances of const MsgPtr & to a simple MsgPtr.
If the function wants to avoid the overhead of creating another
reference, then it should just use a regular pointer instead of a ref
counting ptr.
There were a couple of instances where refcounted objects were created
on the stack. This seems pretty dangerous since if you ever
accidentally make a reference to that object with a ref counting
pointer, bad things are bound to happen.
Diffstat (limited to 'src/mem/ruby/system/CacheMemory.cc')
0 files changed, 0 insertions, 0 deletions