On Saturday, 19 September 2015 at 18:20:16 UTC, Ola Fosheim Grøstad wrote:
> I'm not sure if the current collector scans all registers, or just scans the stack?

According to the docs it scans all registers, but even then one must be careful and do addRoot before the pointer is set, otherwise the CPU might flush the register and a collection could run between setting the pointer and addRoot...?

No, collection could not occure if we speaking about current D GC
implementation. So it safe to set pointer before addRoot.
Dne 19. 9. 2015 21:00 napsal uživatel "Ola Fosheim Grøstad via
Digitalmars-d-announce" <digitalmars-d-announce@puremagic.com>:

> On Saturday, 19 September 2015 at 18:20:16 UTC, Ola Fosheim Grøstad wrote:
>
>> I'm not sure if the current collector scans all registers, or just scans the stack?
>>
>
> According to the docs it scans all registers, but even then one must be careful and do addRoot before the pointer is set, otherwise the CPU might flush the register and a collection could run between setting the pointer and addRoot...?
>
>

On Saturday, 19 September 2015 at 19:17:38 UTC, Daniel Kozak wrote:
> No, collection could not occure if we speaking about current D GC
> implementation. So it safe to set pointer before addRoot.

It can be triggered by another thread.

Wrong:

ptr = somestack.pop();
someglobalptr = ptr;
// ptr register flushed
// collection triggered by other thread
// other thread allocated the same memory for some other object
addRoot(ptr);

Right:

ptr = somestack.pop();
addRoot(ptr);
ensure memory barrier here;
someglobalptr = ptr;

?

On Saturday, 19 September 2015 at 19:25:31 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 19 September 2015 at 19:17:38 UTC, Daniel Kozak wrote:
>> No, collection could not occure if we speaking about current D GC
>> implementation. So it safe to set pointer before addRoot.
>
> It can be triggered by another thread.
>
> Wrong:
>
> ptr = somestack.pop();
> someglobalptr = ptr;
> // ptr register flushed
> // collection triggered by other thread
> // other thread allocated the same memory for some other object
> addRoot(ptr);

Typo:

> addRoot(someglobalptr);

Dne 19.9.2015 v 21:30 Ola Fosheim Grøstad via Digitalmars-d-announce napsal(a):
> On Saturday, 19 September 2015 at 19:25:31 UTC, Ola Fosheim Grøstad wrote:
>> On Saturday, 19 September 2015 at 19:17:38 UTC, Daniel Kozak wrote:
>>> No, collection could not occure if we speaking about current D GC
>>> implementation. So it safe to set pointer before addRoot.
>>
>> It can be triggered by another thread.
>>
>> Wrong:
>>
>> ptr = somestack.pop();
>> someglobalptr = ptr;
>> // ptr register flushed
>> // collection triggered by other thread
>> // other thread allocated the same memory for some other object
>> addRoot(ptr);
>
> Typo:
>
>> addRoot(someglobalptr);
>
Yes, now it seems possible :)

On Friday, 18 September 2015 at 20:46:18 UTC, Jack Stouffer wrote:
> On Friday, 18 September 2015 at 19:26:27 UTC, Rory wrote:
>> The new GC in Go 1.5 seems interesting. What they say about is certainly interesting.
>>
>> http://blog.golang.org/go15gc
>>
>> "To create a garbage collector for the next decade, we turned to an algorithm from decades ago. Go's new garbage collector is a concurrent, tri-color, mark-sweep collector, an idea first proposed by Dijkstra in 1978."
>
> I think this was talked about in general. If I remember correctly the consensus was that
>
> 1. D's GC is really primitive (70's style stop the world) and there's a lot of room for improvement
>
> 2. However, D has much more important problems currently than a slow GC, e.g. std.allocator, a GC-less phobos, smaller .o files for embedded systems, A better DMD with DDMD, etc.
>
> The reason Go has a better GC than D is that Go users have no choice but to use the GC, while D users have a bunch more options.

That's just bad excuses.

On Sunday, 20 September 2015 at 22:41:46 UTC, deadalnix wrote:
> That's just bad excuses.

Excuses? Sure. Bad excuses? Not nearly. The other things I listed are much more important (IMO) than making the GC faster.

On Sunday, 20 September 2015 at 23:43:29 UTC, Jack Stouffer wrote:
> On Sunday, 20 September 2015 at 22:41:46 UTC, deadalnix wrote:
>> That's just bad excuses.
>
> Excuses? Sure. Bad excuses? Not nearly. The other things I listed are much more important (IMO) than making the GC faster.

Most excuses are bad. Users do not care about excuses. These one are especially bad as they do not provide any valid reason why the task is not tackled for years, simply that other tasks that are also of importance are not being tackled either.

X is not important because Y is more important. As a result, we have nothing to show for either X or Y. How can this be anything else than a bad excuse ?

With Andrei working more on D maybe he will find time to document how the compiler works better so more of us can contribute.

On Mon, Sep 21, 2015 at 4:23 AM, deadalnix via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On Sunday, 20 September 2015 at 23:43:29 UTC, Jack Stouffer wrote:
>
>> On Sunday, 20 September 2015 at 22:41:46 UTC, deadalnix wrote:
>>
>>> That's just bad excuses.
>>>
>>
>> Excuses? Sure. Bad excuses? Not nearly. The other things I listed are much more important (IMO) than making the GC faster.
>>
>
> Most excuses are bad. Users do not care about excuses. These one are especially bad as they do not provide any valid reason why the task is not tackled for years, simply that other tasks that are also of importance are not being tackled either.
>
> X is not important because Y is more important. As a result, we have nothing to show for either X or Y. How can this be anything else than a bad excuse ?
>
>

On Sunday, 20 September 2015 at 23:43:29 UTC, Jack Stouffer wrote:
> On Sunday, 20 September 2015 at 22:41:46 UTC, deadalnix wrote:
>> That's just bad excuses.
>
> Excuses? Sure. Bad excuses? Not nearly. The other things I listed are much more important (IMO) than making the GC faster.

The most important thing for a system level language is to get competitive resource management right early on since it is very likely to require language changes. And it has to be more solid than C++ and Rust.