On Thursday, 26 February 2015 at 20:15:37 UTC, Walter Bright wrote:
> I don't really understand your point. Write barriers are emitted for code that is doing a write.

That is exactly the point? When you don't write, you don't pay for write barriers. It is fairly straightforward that the argument that write barrier are expensive and undesirable does not follow for immutable heap.

On Thursday, 26 February 2015 at 19:58:56 UTC, Walter Bright wrote:
> On 2/25/2015 11:01 PM, Benjamin Thaut wrote:
>> What you are describing is a compacting GC and not a generational GC. Please
>> just describe in words how you would do a generational GC without write
>> barriers. Because just as deadalnix wrote, the problem is tracking pointers
>> within the old generation that point to the new generation.
>
> It was a generational gc, I described earlier how it used page faults instead of write barriers. I eventually removed the page fault system because it was faster without it.

Page fault ARE write barrier.

On 2/25/2015 1:27 PM, Benjamin Thaut wrote:
> You seeing this completely one sided. Even if write barries make code slower by
> 10% its a non issue if the GC collections get faster by 10% as well. Then in
> average the program will run at the same speed.

You'll be paying that 10% penalty for every write access, not just for GC data. D is not Java in that D has a lot of objects that are not on the GC heap. Tradeoffs appropriate for Java are not necessarily appropriate for D.

On 2/25/2015 8:39 AM, Manu via Digitalmars-d wrote:
> I'll take the possibility that an ignored
> error code may not result in a hard-crash every time.

If you want some fun, take any system and fill up the disk drive to just short of capacity. Now go about your work using the system.

You'll experience all kinds of delightful, erratic behavior, because real world C code tends to ignore write failures and just carries on.

On 2/26/2015 12:29 PM, deadalnix wrote:
> Page fault ARE write barrier.

When we all start debating what the meaning of "is" is, it's time for me to check out.

Am 26.02.2015 um 21:39 schrieb Walter Bright:
> On 2/25/2015 1:27 PM, Benjamin Thaut wrote:
>> You seeing this completely one sided. Even if write barries make code
>> slower by
>> 10% its a non issue if the GC collections get faster by 10% as well.
>> Then in
>> average the program will run at the same speed.
>
> You'll be paying that 10% penalty for every write access, not just for
> GC data. D is not Java in that D has a lot of objects that are not on
> the GC heap. Tradeoffs appropriate for Java are not necessarily
> appropriate for D.

Write barries only have to be generated for writes to pointers through pointers. So you are not paying a penality for every write.

class Bar
{
  int x;
  Bar other;

  void method()
  {
    x = 5; // no write barrier
    other = this; // write barrier
  }
}

Also the following code will not generate a single write barrier:

void someFunc(uint[] ar)
{
  for(uint* it = someArray.ptr; it < ar.ptr + ar.length; it++)
  {
    *it = 5;
  }
}

Am 26.02.2015 um 20:58 schrieb Walter Bright:
>
> It was a generational gc, I described earlier how it used page faults
> instead of write barriers. I eventually removed the page fault system
> because it was faster without it.

Page faults are inferrior to compiler generated write barriers. Because with a page fault startegy you pay for every write. Even if the write does not write a pointer. Compiler generated write barriers only apply to pointers written through another pointer.

On 2/26/2015 1:15 PM, Benjamin Thaut wrote:
> Am 26.02.2015 um 21:39 schrieb Walter Bright:
>> You'll be paying that 10% penalty for every write access, not just for
>> GC data. D is not Java in that D has a lot of objects that are not on
>> the GC heap. Tradeoffs appropriate for Java are not necessarily
>> appropriate for D.
>
> Write barries only have to be generated for writes to pointers through pointers.

Of course.

> So you are not paying a penality for every write.

Sigh. That does not change the point of what I wrote.

On Thursday, 26 February 2015 at 21:17:57 UTC, Benjamin Thaut wrote:
> Am 26.02.2015 um 20:58 schrieb Walter Bright:
>>
>> It was a generational gc, I described earlier how it used page faults
>> instead of write barriers. I eventually removed the page fault system
>> because it was faster without it.
>
> Page faults are inferrior to compiler generated write barriers. Because with a page fault startegy you pay for every write. Even if the write does not write a pointer. Compiler generated write barriers only apply to pointers written through another pointer.

It is a tradeof.

You can implement write barrier in the codegen. In which case you check them every time, but only for pointers. The check is cheap but creeping.

You can implemented them using memory protection. In which case it is WAY more expensive and will trap all the write, but ONLY when needed (it can be turned on and off) and usually you trap once per page.

Note that in D, you have union and all kind of crap like that, so what is writing a pointer is non obvious and so the tradeof is very different than it is in other languages.

On Thursday, 26 February 2015 at 20:56:25 UTC, Walter Bright wrote:
> On 2/26/2015 12:29 PM, deadalnix wrote:
>> Page fault ARE write barrier.
>
> When we all start debating what the meaning of "is" is, it's time for me to check out.

You are the one playing that game. You said earlier you used MMU as write barrier for a GC in Java, and now you are deciding that this is not a write barrier anymore.

But indeed, that settle the debate. If you are down to redefining things as not write barriers as to pretend you can implement what you redefine as a generational GC (which the rest of the world call a compacting GC) then what is there to discuss ? You don't seems to be up to date about recent GC technologies and/or terminology used in the area.