> - Those DynInst structures do seem huge. Slimming them down seems like it > would be a big win. Sometimes structs are just big. Think about the task struct in linux. Slimming down isn't as important as reordering the values in the structure so that the important ones are in the front and packed densely so that the unimportant stuff gets evicted from the cache. If you really want to make them smaller then I know of two strategies. Break the structure into two pieces and put the unimportant stuff in the second piece. You can either use a pointer from the first piece or a hash table that maps the point from the first to a pointer of the second.
> - I wouldn't take it on faith that FastAlloc is faster. It might be, but I > wrote that a *long* time ago, and malloc has probably improved in the > interim. It's easy to compile without it (I think there's a NO_FAST_ALLOC > flag); it would be interesting to see if that matters. Of course, if most > of the allocations aren't using it anyway, maybe that won't tell the whole > story. My guess is that we should just stop using it since we're heading towards multithreaded code anyway. I'd be quite surprised if it were better than malloc. One real win that we could get is if we could take advantage of partially constructed objects (I think that was in the original slab allocator paper). > - I wonder if all the ref-counting pointer stuff is because we're copying > the pointers a lot instead of sharing references to them (e.g., as > parameters to short function calls). Basically you end up incrementing > then deleting the ref count if you pass a pointer by value instead of by > reference, IIRC. This is an optimization that could lead to confusion if all are not on board: There really is no reason that we should be using RefCountingPtr instead of a regular pointer when calling a function or as a local variable in a function. RefCountingPtr really should only be used when saving a pointer in some sort of datastructure (i.e. as a member variable of a class, or as a value in some STL struct.) Make sense? We could of course start being more conscious of these rules and for the parts of the system that make big use of these pointers, use the regular ones. Like to avoid confusion though. Perhaps by doing something like: typedef RefCountingPtr<Foo> FooSavedPtr; typedef Foo *FooTempPtr; Nate _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
