I was just wondering whether it would make sense to have custom allocators defined for Request and Packet types which would keep around a pool of them rather than defaulting to the normal allocator. I suspect since both types of objects are allocated very frequently this could save a lot of heap overhead.
I think there are two complications to doing this. First, we'd want to make sure Request and Packet objects are truly those objects and are of the appropriate size. Subclasses could add new members and make the types bigger. I think to ensure that, we'd need to add the "final" keyword (added in C++11) to ensure those types can't be subclassed and have unpredictable sizes. Second, we use make_shared a lot to build Requests, and that actually allocates a larger amount of memory to hold the object and reference count information. It allocates that larger object with new, and it looks like you're supposed to use allocate_shared if you want to use a custom allocator. Writing a custom allocator looks relatively complicated, but it might make a big difference if it works correctly. Also we'd probably want to put the Request allocator incantation in a small function rather than calling make_shared or allocate_shared directly to avoid a lot of boilerplate and churn if things need to change. Thoughts? Like I said I suspect this may make a significant difference, but it might not be easy to implement and may not actually make much of a difference at all. Gabe _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
