News for hackers. Stuff that matters.
Re:The D Garbage Collector by pcwalton on Monday March 20, 2017 @02:27PM (#13916455)
> 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?

Re:The D Garbage Collector by p0nce on Monday March 20, 2017 @02:35PM (#13916520)
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.
Re:The D Garbage Collector by pcwalton on Monday March 20, 2017 @02:40PM (#13916566)
If you can safely disable the GC, then you can safely disable write barriers.
Re:The D Garbage Collector by p0nce on Monday March 20, 2017 @02:51PM (#13916655)
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.

Re:The D Garbage Collector by pcwalton on Monday March 20, 2017 @03:17PM (#13916868)
If the compiler can statically tell which pointers point to GC memory (something it usually needs to know anyway), yes.
Re:The D Garbage Collector by p0nce on Monday March 20, 2017 @04:23PM (#13917365)
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.
Re:The D Garbage Collector by pcwalton on Monday March 20, 2017 @10:04PM (#13919256)
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.