Potential GSoC project - GC improvements

[ZombineDev via Digitalmars-d]

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.