Re: DConf 2013 Day 2 Talk 5: A Precise Garbage Collector for D by Rainer Schütze

[Rainer Schuetze]

On 01.07.2013 12:30, bearophile wrote:
> Rainer Schuetze:
>
>> In the proposed implementation, the gc_emplace function can be used to
>> pass this information to the GC. This would need to be called whenever
>> the location of pointers changes, so it's not high-performance.
>
> Thank you for the answer.
>
> Let me see if I understand what you are saying. If I have an usage of
> Algebraic like this, at line 4 x contains no GC-managed pointers, while
> at line 6 it contains a pointer to the array data:
>
>
> import std.variant: Algebraic;
> void main() {
>      alias T = Algebraic!(ulong, int[]);
>      T x = 1UL;  // line 4
>      auto items = [1, 2];
>      x = items; // line 6
>      x = 2UL;   // line 7
>      x = items; // line 8
> }
>
>
> You say that every time you change the _type_ of the contents of x you
> have to call gc_emplace.

Yes, that would be Algebraic's responsibility. An optimization is to 
only do it if the respective pointer info changes, but that would tie it 
a bit more to the GC implementation.

In your example, x is a stack variable, so as long as there is no 
precise scanning of the stack, that actually generates a lot of useless 
interaction with the GC.

>
> But isn't the D GC called only when an allocation occurs? So what's the
> point of calling gc_emplace (at lines 7 and 8) if no garbage collection
> happens? Isn't it possible for the GC to use (and update) this
> information lazily, only when a collection occurs?

I was thinking about allowing some callback to do the scanning, but that 
has some serious drawbacks:

- it is not easily composable if structs like Algebraic are fields of a 
class/struct. You would not want to call a function for every field.

- having to call a (virtual) scanning function for every allocated 
object is probably also a performance killer, though I haven't tried it yet.

- it does not allow very unpredictable usages of memory using std.emplace.

Doing just the pointer bitmap update lazily is an interesting idea, 
though I'm not sure if it is actually less work to cache this info than 
to update the bitmap immediately.

>
> (Extra note: Algebraic is meant for functional-style programming. In
> such kind of programming data is mostly immutable. This means you don't
> change the contents and the type of an algebraic variable once it is
> assigned. So usually you call gc_emplace only once for one of such
> variables).
>
> Bye,
> bearophile