If using tcmalloc or other malloc optimizations are untenable, would Nilay's idea be something to consider (static allocation of a memory chunk to be used by dyninsts)?
I'm thinking FastAlloc may do something similar but I think the DynInsts are a special case because we know at initialization times the max amount of DynInsts per CPU that can be live. Thus, if these memory allocators aren't already doing something very similar, it seems to be the best solution is to do all our allocation of this upfront and then have some wrapper code to manage pre-allocated dyninsts (wouldnt be too hard actually as it's something I've already considered/implemented for parts of the inorder model that may be too new/delete happy). Finally, if someone implemented that, that would subvert the potential problems of extra dependencies to add for gem5 users. Thoughts? On Tue, May 29, 2012 at 3:34 PM, Steve Reinhardt <[email protected]> wrote: > On the "slimming down" front, one thing to do is make sure we're using the > smallest fields possible, particularly for arrays. For example, I see that > RegIndex is uint16_t for most architectures, which seems like overkill. > Also, in src/cpu/o3/dyn_inst.hh I see: > > int _destMiscRegIdx[MaxInstDestRegs]; > > which I expect should be RegIndex rather than int. > > Steve > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > -- - Korey _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
