I haven't had a chance to really consider it carefully, but it seems reasonable to me. One danger might be if the fast allocator changes behavior in such a way that bugs that show up in m5.opt go away in m5.debug when it's turned off. I've run into sort of the opposite of that before I think with visual studio (long, long ago) where the debug version was actually much more lenient about array bounds and that sort of thing and effectively hid the bug from me. If there's a way to force things to be consistent that would be help mitigate any issues, assuming any exist. Like I said I haven't thought it about it too deeply.
It should be pretty easy to see what the performance difference is with and without fast alloc, right? We have a switch to turn it on and off? Gabe On 03/10/11 14:11, nathan binkert wrote: > Seems reasonable. One question. Do we know that FAST_ALLOC actually > is faster than the built in allocator? It's pretty darned old and > memory allocators are pretty modern now. > > Nate > > On Thu, Mar 10, 2011 at 8:23 AM, Steve Reinhardt <ste...@gmail.com> wrote: >> Brad pointed out that he habitually sets NO_FAST_ALLOC when compiling >> m5.debug because the way FastAlloc handles memory allocation tends to be >> tolerant of memory allocation errors (like reusing objects after they've >> been deleted), and he's run across other people's bugs simply by running >> with NO_FAST_ALLOC. I pointed out that he's abusing the purpose of a sticky >> config variable by toggling it based on which binary he's compiling, but he >> didn't seem to care ;-). >> >> He has a good point though, so what I would like to do is condition the use >> of FastAlloc on whether DEBUG is set. While this sounds straightforward, >> there are several minor complications I want to solicit input on before I do >> this. (Though of course people are free to object with the basic premise if >> they choose.) >> >> - It seems like there should be a way to force FastAlloc to be on even for >> m5.debug, on the off chance you might want to debug FastAlloc itself, or if >> there's some other bug that presents itself more readily in combination with >> FastAlloc. I propose adding a FORCE_FAST_ALLOC sticky config var to do >> this. >> >> - There's some code protected by '#if FAST_ALLOC_DEBUG' that is intended to >> help debug memory leaks using FastAlloc. I've used it once or twice, but I >> kind of doubt that anyone else has, and I'm sure it's not as good as using >> valgrind or probably several other malloc debug packages. It seems >> particuarly ironic to have debug code in a module that is disabled in >> m5.debug, so I propose getting rid of this. That would also let us get rid >> of the FAST_ALLOC_DEBUG scons sticky var, so we'd be at a wash in terms of >> sticky var count. >> >> Any comments? >> >> Steve >> _______________________________________________ >> m5-dev mailing list >> m5-dev@m5sim.org >> http://m5sim.org/mailman/listinfo/m5-dev >> > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
