This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Discussion on Removal of Garbage Collector and other GCC Multi threaded Work
- From: David Malcolm <dmalcolm at redhat dot com>
- To: Nicholas Krause <xerofoify at gmail dot com>, gcc Mailing List <gcc at gcc dot gnu dot org>
- Date: Thu, 27 Feb 2020 15:02:13 -0500
- Subject: Re: Discussion on Removal of Garbage Collector and other GCC Multi threaded Work
- References: <42be02a3-cfe8-3cae-2350-e3e80e1d3a13@gmail.com>
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
>