Potential GSoC project - GC improvements

[ZombineDev via Digitalmars-d]

On Thursday, 10 March 2016 at 18:49:28 UTC, Daniel Kozak wrote:
>
>
> Dne 10.3.2016 v 19:39 ZombineDev via Digitalmars-d napsal(a):
>> On Thursday, 10 March 2016 at 17:46:15 UTC, Daniel Kozak wrote:
>>>
>>>
>>> Dne 10.3.2016 v 18:15 ZombineDev via Digitalmars-d napsal(a):
>>>> On Thursday, 10 March 2016 at 16:46:59 UTC, Jeremy DeHaan 
>>>> wrote:
>>>>> On Thursday, 10 March 2016 at 15:24:48 UTC, Andrei 
>>>>> Alexandrescu wrote:
>>>>>> On 3/9/16 10:40 PM, NX wrote:
>>>>>>> I think the best possible improvement for GC is making it 
>>>>>>> lock-free.
>>>>>>> Currently, GC lock cause some serious performance 
>>>>>>> penalties for
>>>>>>> multithreaded code when frequent allocations take place.
>>>>>>
>>>>>> I agree. A first step would be easy to do with 
>>>>>> std.allocator's thread-local freelists. -- Andrei
>>>>>
>>>>> I was looking into this, but I am slightly hesitant. Should 
>>>>> the gc use something in std.experimental? Or should we 
>>>>> think that's ok?
>>>>>
>>>>> I also know that there are some people that think we should 
>>>>> avoid using Phobos in druntime.
>>>>
>>>> There's no problem in using std.experimental.* internally, 
>>>> because if the API changes, the one who changes the API will 
>>>> also need to change all internal usages, otherwise his pull 
>>>> request won't compile.
>>>>
>>>> About using Phobos in Druntime - you can't directly import 
>>>> Phobos, since it's files are not present when Druntime is 
>>>> built.
>>> But we allready need existing D compiler to build D frontend, 
>>> so maybe we can use this full D compiler for building 
>>> druntime in the future?
>>
>> The build process looks something like this currently:
>> (a bit simplified)
>> 1. Download old dmd.
>> 2. Build new dmd with 1.
>> 3. Build druntime with 2.
>> 4. Build phobos with 2 and link it with 3.
>> 5. Package 2, 3 and 4 into a release zip
>>
>> You can't use 1 for building 3 (or 4), because 3 (or 4) may 
>> depend on a new feature only present in 2. Also you can't rely 
>> on 5 for building 3 (or 4) because you'll get a cyclic 
>> dependency.
>
> I know how it works now :). But if D is stable enought  1 
> should be good enought to do 3 and 4 (yes you can't rely on 
> features and fixes from 2). I think we should avoid to use 
> latest features when developing dmd, druntime and phobos (maybe 
> we should use only some subset or make some rules like new 
> version must be compilable by 3 previous version of dmd)

Well for 4. maybe, but after a couple of years... Most of the 
time Phobos can't be compiled with an older version of DMD not 
because it relies on new features, but because there are bugs in 
the older version of DMD.
As for 3. - druntime is very tightly coupled with the compiler. 
Quite often changes in the compiler rely on changes in druntime - 
e.g. the new DWARF exceptions, C++ and Objective-C support, 
better code coverage and GC profiling, things in object.d, 
built-in AAs and arrays, linking with MSVC 2015 libc, shared 
libraries, TLS, etc.
On the other hand, I think that using Phobos in DMDFE is a good 
idea and is far more likely to happen.