[D-runtime] Precise garbage collection

[Leandro Lucarella]

On Sat, Jun 22, 2013 at 12:11:17AM -0700, Walter Bright wrote:
> >d. The alternative to using a pointer bitmap alongside the pool
> >memory is to store the TypeInfo pointer instead. It's major
> >advantage is that it adds minimal performance overhead to the
> >allocation.
> 
> But it'll subtract performance from the scanner. Which is better can
> only be determined with testing.

I once played with this option (storing a pointer to a TypeInfo) and had
questionable results. Here are a couple of blog posts related to it:
http://www.llucax.com.ar/blog/blog/post/098ceae8
http://www.llucax.com.ar/blog/blog/post/1490c03e

> >f. Currently, the precise GC can be versioned in/out, but I think
> >making it a runtime option is preferable. A problem here is that
> >the user has no way to change the default configuration before the
> >GC is initialized.
> >I could imagine always starting with the precise GC, but the user
> >can opt out anytime. The GC could then release any additional
> >memory it has allocated for precise scanning. If the user opts
> >back in, the data structures are rebuilt assuming everything
> >allocated so far as void[].
> 
> I don't think a runtime option is practical. It would be so "expert
> only" that those experts should be able to rebuild the library as
> required.

I'll repeat what I said in my talk. I think the "rebuild" option is an
extremely bad idea. Here at sociomantic we have some applications that
need the concurrent GC (almost all) and some that need the old one
(basically because of the glibc mutex when multi-threading). It would be
EXTREMELY inconvenient having to build 2 different standard libraries
and having to switch between them while compiling. I think even having
to recompile a standard library/runtime is completely "development
mode", but doesn't work for "production mode" (as described by Don) at
all! Is absurd to ask somebody to even recompile a runtime library, you
should be able to use different GC options out of the box.

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.

But please, please, please, don't make GC option (or any runtime option)
only configurable at build-time. We already have the experience of
"mem_stomp" and "sentinel", 2 EXTREMELY USEFUL debug helpers that
ABSOLUTELY NOBODY KNOW OR USE.

I can port the configuration via environment variables to druntime ASAP
if that's helpful.

> >Another option might be to make it a link time option, but that
> >would mean the "standard" gc could not be part of the runtime
> >library to be exchangeable.
> 
> Users really only want one gc.
                            ^
                      CONFIGURABLE

> >5. How do you prefer enabling/disabling precise garbage
> >collection? Versioning/linking/runtime?
> 
> We should pick precise collection and commit to it. And then add
> Leandro's concurrent collector on top!

runtime, initialization-time and/or at source code level (I have the
feeling that there should be a way :).

Please, don't make it a compile time option. A link-time option could be
an option but I think is way too complicated.

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