Go 1.5

[Rory McGuire via Digitalmars-d-announce]

The impression I got reading the article was that their GC was very much
like our current one except that the marking part of the algorithm was run
concurrently.

That is the only reason I shared the article. To me it seems one should be
to mark variables/types with which style of memory management it should
use. I suppose that is what allocators are becoming.
Perhaps someone will write a concurrent generational garbage collected
allocator.

On Sat, Sep 19, 2015 at 10:36 AM, thedeemon via Digitalmars-d-announce <
digitalmars-d-announce at puremagic.com> 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.
>>
>
> They went the way of classical GC-ed language where write barriers are
> used actively, allowing to make concurrent, incremental and (eventually, if
> not yet) generational GC. However it has a cost - pointer field updates are
> slower than in plain C/C++/D, and overall speed is close to Java. D tries
> to be like C and C++ where simple code is fast and straightforward, there
> are no write barriers and there will never be, without changing the
> language design. It means D's GC will always be dog slow - it has to stop
> the world and scan full heap every time. And that leads to different usage
> pattern where GC heap should remain small and GC allocation rate low.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20150919/5a3c36cf/attachment.html>