5 ms·

A fast copying collector for D would require write barriers: using memory barriers everytime a pointer is written. This has a runtime cost. > which runs at eve

• dbaupp 10y ago
  > This has a runtime cost. As does using a conservative/"very slow" GC. I'm sceptical, but it may be that D's situation means trading a pervasive slowness (if the parent is true, I don't know) for no write barriers is the right choice, differing to the conventional wisdom from other languages, but that's the argument you need to make, not just that write barriers are slow.
  • atilaneves 10y ago
    The slow GC is only a runtime cost if it ever runs. If no garbage is created in inner loops and stack allocation is preferred there's no reason it _has_ to run.
  • p0nce 10y ago
    The case against write barriers is pretty simple: the slowness of the GC can be workarounded, while memory barriers cannot. If they are needed, no other way to copy pointer values (which are quite pervasive in system programming).
    • pcwalton 10y ago
      > The case against write barriers is pretty simple: the slowness of the GC can be workarounded, while memory barriers cannot. What workaround do you have in mind, and how does it not apply to write barriers?
      • p0nce 10y ago
        You can always use less of the GC, but there are no way not to use pointers. For example, I sell products in D which disable the GC completely, I certainly don't want write barriers.
        • pcwalton 10y ago
          If you can safely disable the GC, then you can safely disable write barriers.
          • p0nce 10y ago
            And if I use only a bit of the GC, can I use only a bit of write barriers? Walter Bright was right about segmented stacks, I'm tempted to think he's right about write barriers too.
            • pcwalton 10y ago
              If the compiler can statically tell which pointers point to GC memory (something it usually needs to know anyway), yes.
              • p0nce 10y ago
                In D this is indeed known only at runtime, one of the decision was that "there should be only one type of pointers". immutable(T) doesn't guarantee it isn't in the GC heap from what I can gather. shared(T) could perhaps do it, but it's rather unpopular.
                • pcwalton 10y ago
                  If you really don't know until runtime what heap a pointer is in, then write barriers will have some kind of cost, but it should be low (definitely not atomic). However, if you don't know statically what kind of heap a pointer is in, you're going to have a poorly performing GC system no matter what.
• pcwalton 10y ago
  > A fast copying collector would require write barriers: using atomics everytime a pointer is written. No, for two reasons: 1. Write barriers are not necessary if an object is in a nursery, which is true for most objects per the generational hypothesis. This is trivial to check based on the pointer value. 2. You can have thread local remembered sets.
  • p0nce 10y ago
    I read this in http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html http://www.infognition.com/blog/2014/the_real_problem_with_g... better ask the author of the article if you have a way for a better D GC. > To make fast GC it needs to be generational, but generational GC means write barriers: you can't just freely mutate memory, every pointer mutation must be accompanied by additional bookkeeping. I guess that in the context of D generations are not possible or practical. If you have any idea why it should be possible, you may write a DIP.
    • WalterBright 10y ago
      It's possible to do generational collection in D. I've written one before and was careful to design the semantics of D to allow for it. It just needs someone to spend the time to implement it (the core language doesn't need to change). I'm skeptical, however, if it will offer a real improvement.
  • rurban 10y ago
    And 3rd: use forwarding pointers. Every good implementation uses #3.
  • rurban 10y ago
    And 3rd: use forwarding pointers. Every good implementation uses #3.
  • valarauca1 10y ago
    >Write barriers are not necessary if an object is in a nursery, which is true for most objects per the generational hypothesis. This is trivial to check based on the pointer value. Yes but what when it leaves it? You have to update all pointers to another location. When it passes to the Gen2 slab all references that point to it need to be updated, and those changes need to propagate to all threads, and all cores. The simplest way to do this is a memory barrier. Well the real simplest way is just "never multi-thread" and this is OCaml's GC is so fast. No write barriers, 1 thread only, final destination.
• rbehrends 10y ago
  > A fast copying collector would require write barriers: using atomics everytime a pointer is written. This is not how garbage collectors work. At all.
  • p0nce 10y ago
    Let me amend then: "A fast copying collector _in D_ would require write barriers". Of course with other languages you can have GC without that limitation.
    • rbehrends 10y ago
      No, unless there's some subtle semantic detail about D that I am missing. This is just not how GCs work. Write barriers, yes. Write barriers that require atomic instructions every time a pointer is written, no.
      • p0nce 10y ago
        I meant "memory barriers". Atomics embed memory barriers.
        • rbehrends 10y ago
          It sounds like you're confusing two types of "write barriers" that happen to share the same name, but have otherwise little in common. Memory barriers for atomic instructions are essential for giving them sane semantics, but have nothing to do with GC. GC write barriers deal with the needs of generational or incremental collections, but are a totally different thing.
          • p0nce 10y ago
            Yes I thought GC write barriers were always implemented with memory barrier instructions. Probably a trap because the same word is used. Still I wonder how they are implemented then.