3 ms·

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

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.
    - rbehrends 10y ago
      There are a number of solutions. One of the simplest ones (popularized by the JVM) is card marking [1], where each memory page (usually shorter than an actual OS page) has a byte associated with it that is set to a non-zero value when a pointer in that segment is written. Because that change is an idempotent operation, it can be done without coordination between threads. [1] http://blog.ragozin.info/2011/06/understanding-gc-pauses-in-jvm-hotspots.html http://blog.ragozin.info/2011/06/understanding-gc-pauses-in-...
    - dumael 10y ago
      GC write barriers are implemented by expanding sequences that update pointers to perform some sort of additional action. Their purpose is to capture some information about the updated pointer that the GC can then use to avoid a full heap scan. Card marking marks a 'region' as dirty (such as 128/256/512 bytes of memory). This buffer recording the dirty/clean areas is rescanned as part of the evacuation of the generation being collected. Any pointers to the generation then being collected are updated. Sequential store buffers (SSBs) can be used to record the address of the object being updated or a pointer to the pointer itself. Again rescanned during collection. SSBs can be easily thread-local avoiding the need for thread synchronisation, except during a collection cycle which already requires thread synchronisation. Write barrier tend to be optimised heavily as they're used quite frequently. The use of atomic barriers or branch instructions (barring fast path exits) would inhibit performance.

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.
  - rbehrends 10y ago
    There are a number of solutions. One of the simplest ones (popularized by the JVM) is card marking [1], where each memory page (usually shorter than an actual OS page) has a byte associated with it that is set to a non-zero value when a pointer in that segment is written. Because that change is an idempotent operation, it can be done without coordination between threads. [1] http://blog.ragozin.info/2011/06/understanding-gc-pauses-in-jvm-hotspots.html http://blog.ragozin.info/2011/06/understanding-gc-pauses-in-...
  - dumael 10y ago
    GC write barriers are implemented by expanding sequences that update pointers to perform some sort of additional action. Their purpose is to capture some information about the updated pointer that the GC can then use to avoid a full heap scan. Card marking marks a 'region' as dirty (such as 128/256/512 bytes of memory). This buffer recording the dirty/clean areas is rescanned as part of the evacuation of the generation being collected. Any pointers to the generation then being collected are updated. Sequential store buffers (SSBs) can be used to record the address of the object being updated or a pointer to the pointer itself. Again rescanned during collection. SSBs can be easily thread-local avoiding the need for thread synchronisation, except during a collection cycle which already requires thread synchronisation. Write barrier tend to be optimised heavily as they're used quite frequently. The use of atomic barriers or branch instructions (barring fast path exits) would inhibit performance.