On Jun 14, 2013, at 8:21 PM, David Malcolm <dmalc...@redhat.com> wrote: > I'm hoping that gcc 4.9 can support multiple "parallel universes" of gcc > state within one process
> One issue with the above is the garbage collector. > I think there are two possible ways in which "universe instances" could > interact with the GC: > > (a) have the universe instances be GC-managed: all parallel universes > share the same heap, requiring a rewrite of the GC code to be > thread-safe, Yeah, I think going this route would be bad. The extra locking won't win in the end. > I don't think (a) is feasible. I agree. > Hence (a) would require all threads to synchronize on GC-safe locations. Yup. > It seems much simpler to me to go with (b): multiple independent > GC-heaps. Yup. > 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. > 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. > 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%.
