Hi all !
https://github.com/dlang/druntime/pull/1603

Can someone investigate and bring it to us ?
4 years passed from gsoc 2013 and there's still no gc.
Many apps suffers from false pointers and bringing such a gc will help those who affected by it.
It seems all the tests are passed except win32 because of optlink failures.
Maybe there's some chance to accelerate this PR ?

Thanks all

On 11/22/17 02:53, Temtaime wrote:
> Hi all !
> https://github.com/dlang/druntime/pull/1603
>
> Can someone investigate and bring it to us ?
> 4 years passed from gsoc 2013 and there's still no gc.
> Many apps suffers from false pointers and bringing such a gc will help
> those who affected by it.
> It seems all the tests are passed except win32 because of optlink failures.
> Maybe there's some chance to accelerate this PR ?
>
> Thanks all
+1

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

On Wednesday, 22 November 2017 at 10:53:45 UTC, Temtaime wrote:
> Hi all !
> https://github.com/dlang/druntime/pull/1603

Only the Win32 build fails as

Error: more than 32767 symbols in object file

What's wrong?

On Wednesday, 22 November 2017 at 13:23:54 UTC, Nordlöw wrote:
> On Wednesday, 22 November 2017 at 10:53:45 UTC, Temtaime wrote:
>> Hi all !
>> https://github.com/dlang/druntime/pull/1603
>
> Only the Win32 build fails as
>
> Error: more than 32767 symbols in object file
>
> What's wrong?

Thats a linker(?) limitation for OMF (or whatever is the win32 object file format).

On 11/22/17 05:44, Nicholas Wilson wrote:
> On Wednesday, 22 November 2017 at 13:23:54 UTC, Nordlöw wrote:
>> On Wednesday, 22 November 2017 at 10:53:45 UTC, Temtaime wrote:
>>> Hi all !
>>> https://github.com/dlang/druntime/pull/1603
>>
>> Only the Win32 build fails as
>>
>> Error: more than 32767 symbols in object file
>>
>> What's wrong?
>
> Thats a linker(?) limitation for OMF (or whatever is the win32 object
> file format).

We really should be using the MSVC linker on Windows for both x86 and x64.

I propose we change the default behavior of -m32 to point to MSVC, keep the -m32mscoff, but mark it as deprecated, and add a -m32omf flag to retain the current behavior.

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

On Wednesday, 22 November 2017 at 13:44:22 UTC, Nicholas Wilson wrote:
> Thats a linker(?) limitation for OMF (or whatever is the win32 object file format).

Was just fixed!

What improvements to D's concurrency model is made possible with this precise GC?

I recall Martin Nowak saying at DConf 2016 that

a precise GC will enable data with isolated or immutable indirections to be safely moved between threads

On 11/23/17 02:47, Nordlöw wrote:
> On Wednesday, 22 November 2017 at 13:44:22 UTC, Nicholas Wilson wrote:
>> Thats a linker(?) limitation for OMF (or whatever is the win32 object
>> file format).
>
> Was just fixed!
>
> What improvements to D's concurrency model is made possible with this
> precise GC?
>
> I recall Martin Nowak saying at DConf 2016 that
>
> a precise GC will enable data with isolated or immutable indirections to
> be safely moved between threads

Rainer is awesome!

That is certainly one aspect that it will enable.

I would focus on a generational GC first for two reasons. The first is that you can delay the scans of the later gens if the Gen0 (nursery) has enough space, so for a lot of programs it would result in a significant cut-down in collection times.

The second is that you still typically have to stop the execution of the thread on the Gen0 collection (the objects most likely to be hot). So with a non-generational concurrent collector you have to stop the thread for the entirety of the scan, because you have no way to know which objects are hot and which are cold.

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

On Thursday, 23 November 2017 at 20:13:31 UTC, Adam Wilson wrote:
> I would focus on a generational GC first for two reasons. The

But generational GC only makes sense if many of your GC objects have a short life span. I don't think this fits well with sensible use of a language like D where you typically would try to put such allocations on the stack and/or use RAII or even an arena.

> The second is that you still typically have to stop the execution of the thread on the Gen0 collection (the objects most likely to be hot). So with a non-generational concurrent collector you have to stop the thread for the entirety of the scan, because you have no way to know which objects are hot and which are cold.

How are you going to prove that references are all kept within the generation in D? There is some very costly book keeping involved that simply don't work well with D semantics.

On 11/23/17 13:40, Ola Fosheim Grøstad wrote:
> On Thursday, 23 November 2017 at 20:13:31 UTC, Adam Wilson wrote:
>> I would focus on a generational GC first for two reasons. The
>
> But generational GC only makes sense if many of your GC objects have a
> short life span. I don't think this fits well with sensible use of a
> language like D where you typically would try to put such allocations on
> the stack and/or use RAII or even an arena.
>

Sensible to whom? The great thing about D is that it works just we well for low-level people who need to wring the most out of the metal, AND the high-level productivity minded apps people, who don't.

RAII+stack allocations make sense when I care about WHEN an object is released and wish to provide some semblance of control over deallocation (although as Andrei has pointed out numerous time, you have no idea how many objects are hiding under that RAII pointer). But there are plenty of use cases where I really don't care when memory is released, or even how long it takes to release.

For example, all of the D apps that I've written and use in production, GC-allocate everything. I don't have a single struct in the code. But I don't care, because the program is so short lived and the working set so small that there will never be GC collection. And it's not like this is an uncommon or unwise pattern in D, DMD itself follows this exact pattern. Obviously my pattern isn't "wrong" or else DMD itself is "wrong". It's just not your definition of "correct".

Another use case where RAII makes no sense is GUI apps. The object graph required to maintain the state of all those widgets can be an absolute performance nightmare on destruction. Closing a window can result in the destruction of tens-of-thousands of objects (I've worked on codebases like that), all from the GUI thread, causing a hang, and a bad user experience. Or you could use a concurrent GC and pass off the collection to a different thread. (See .NET)

>> The second is that you still typically have to stop the execution of
>> the thread on the Gen0 collection (the objects most likely to be hot).
>> So with a non-generational concurrent collector you have to stop the
>> thread for the entirety of the scan, because you have no way to know
>> which objects are hot and which are cold.
>
> How are you going to prove that references are all kept within the
> generation in D? There is some very costly book keeping involved that
> simply don't work well with D semantics.
>
>

Again, which semantics? If you compile with -betterc, the bookkeeping and it's overhead simply don't exist.

Your arguments are based on a presupposition that D should only be used a certain way; a way that, I am sure, mirrors your own usage patterns. D supports a multitude of different usage patterns, some of which look nothing like what you are holding up as "correct". And this is what makes D special. To remove or dismiss as invalid those usage patterns would be detrimental to those of us who use them and be catastrophic to D in general.

As a community, can we please stop it with the subjective judgements of what is and is not "sensible" in D, and start supporting the people using it, however they are using it, even if we are sure that they are "wrong"?

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

On Friday, 24 November 2017 at 05:34:14 UTC, Adam Wilson wrote:
> On 11/23/17 13:40, Ola Fosheim Grøstad wrote:
>> On Thursday, 23 November 2017 at 20:13:31 UTC, Adam Wilson wrote:
>>> I would focus on a generational GC first for two reasons. The
>>
>> But generational GC only makes sense if many of your GC objects have a
>> short life span. I don't think this fits well with sensible use of a
>> language like D where you typically would try to put such allocations on
>> the stack and/or use RAII or even an arena.
>>
>
> Sensible to whom? The great thing about D is that it works just we well for low-level people who need to wring the most out of the metal, AND the high-level productivity minded apps people, who don't.
>

The problem with generational GC is “write barriers” - pieces of code compiler needs to insert around every write of a pointer.

Now given that we can cast pointer to integer and back (also unions), I don’t see how it would work unless we put write barriers everywhere on the off-chance it did wrote a pointer from OLD to NEW space.

A better GC is a great direction. Generational one is not feasible unless we disallow quite a few of our features.