On Sat, 2013-06-15 at 12:09 -0700, Mike Stump wrote: > On Jun 14, 2013, at 8:21 PM, David Malcolm <dmalc...@redhat.com> > wrote:
[...snip discussion of approaches to GC and state...] > > I'm attaching a patch which converts all state within ggc into a > gc_heap > > class, so that you can have multiple instances of ggc heaps. For > now > > there's a singleton instance "the_heap", which is used implicitly in > a > > few places. > > I like the design. Thanks! > > I don't yet know to what extent this affects performance of the > garbage > > collector (extra register pressure from passing around "this", > > perhaps?). > > Would be nice to do a release style build (gcc trunk will default to > lots of extra checking, since it isn't a release) and gather > performance numbers for it. Thanks for the pointer: this is: --enable-checking=release right? > > Thoughts? > > I looked through the patch, and it looks reasonable to me (informal > code review). I think for formal review, the reviewer should see and > consider the performance impact. You can do something just a hair > wrong, and kill performance. So, a C++ generate a pch file, say of > 100,000 lines or typical C++ code, and see the time of an -O2 and a > -O0 build. -O0 influence the edit->debug cycle time. If performance > is more than 30% off, it would seem you should be able to regain that > by fixing your code. I'd hope than pch generation time is slower than > less than 3%, ideally, around 0.4%. Good to have some numbers to aim at. FWIW, this isn't the first discussion on this list about the possibly performance impact of introducing a singleton: we had a similar discussion in another thread about removing state from passes. One idea there was to introduce a macro to add "static" to all methods and fields when not building shared libraries, to lose the "this" pointers: http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01351.html which might be applicable in this case. I think this issue will keep popping up. I've been writing up some notes that I hope can form a plan for removing global state from GCC; I hope to post it soon (though it's gotten *very* long). Thanks again for looking at the patch. Dave
