[D-runtime] Precise garbage collection

[Leandro Lucarella]

On Mon, Jun 24, 2013 at 08:29:36PM +0200, Rainer Schuetze wrote:
> On 24.06.2013 11:19, Leandro Lucarella wrote:
> >I'll repeat what I said in my talk. I think the "rebuild" option is an
> >extremely bad idea.
> 
> Especially in the transition to precise GC I would expect one or two
> hickups and everybody will tend to blame the changed GC. It should
> be easy to switch to non-precise GC to verify if the accusation is
> rectified.

Yes, at first I would even leave it disabled by default, so only the
courageous ones can test it (like for real, not just for a week in the
"beta testing"). I would even say to wait a couple of releases or more
to enable it by default, this will allow us to get a lot of "real world
experiences" without disturbing people that don't really care ("Why did
you break my code when I don't even need precise scanning?!").

It has to be easily enabled for people to test it though ;)

> >I used "initialization-time" configurability in CDGC and worked pretty
> >well. It would be much more convenient to have a way to change GC
> >options at source code level too, but I had the same problem, I couldn't
> >find a way to do anything before the GC is initialized. I think being
> >able to configure runtime options via environment variables is an
> >extremely convenient option.
> 
> I was thinking about environment variables aswell, but that's not so
> convenient for applications run by non-developers.

Very true.

> One way to do it might be to put configuration variables into a
> module gc.config (it might still read environment variables to
> change defaults). This module is part of the druntime library. If
> the programmer then provides a different gc.config that fulfills all
> the link dependencies, on the link command line, it is preferred
> over the module from the library.

Mmm, interesting. I thought about something similar but with a function
(that would return a similar struct). I think the configuration
mechanism should be part of the runtime, not only the GC, there are
other runtime stuff that can or could be configured.

> One thing I'll do for sure is to convert versions(GC_PRECISE) to
> if(gc_precise), so it is easy to switch between a configuration
> variable and an enum that allows the optimizer to just remove the
> disabled parts.

Good. I would say to just use that and then we can figure out where that
gc_precise can come from. Maybe just configuration through environment
variables is good enough as a start for people wanting to try it to be
able to enable it easily.

-- 
Leandro Lucarella
Senior R&D Developer
Sociomantic Labs GmbH <http://www.sociomantic.com>