On Thu, 2020-02-27 at 14:07 -0500, Nicholas Krause wrote: > Greetings All, > > After doing some more research it seems that it may be time to > remove > the garbage collector. I'm > aware of the linkage to precompiled headers but even them I think > its > time due to two reasons: > > 1. The work related to multithreading gcc is working around the > global > state of the collector which > makes scaling less likely in terms of threads. In addition it is > causing unnecessary compilations > in terms of workarounds in this project. > > 2. Memory usage may be decreased in certain passes due to being able > to > implement memory allocation > at a pass or per pass type level with more knowledge than a generic > garbage collector. I'm aware this > is done for a lot of passes. However it could be done for the other > passes that are linked currently to the > garbage collector. > > I'm not sure what memory allocation strategies we want to implement > in > terms of replacing the garbage > collector but I think its time.
Nick, you've sent various emails to this list suggesting big changes to GCC's codebase (updating from C++98 to C++11 is another one that springs to mind), but I believe you've yet to send the project an actual patch for anything. It's great that you want to help, and that you have ideas about the high-level architecture of the project, but may I respectfully suggest you start with something *much* smaller and more concrete? There are plenty of bugs in BZ that could use attention. Hope this is constructive David > On another I'm looking into the issues with PHI nodes and operators > as > to how to lock or decrease global > state there as this seems to be the biggest complication when I've > time. > In addition as Jeff stated we > will also want to encapsulate SSA operands and other SSA related > things > in a series of classes as part of > this. > > > Regards, > Nick >
