Potential GSoC project - GC improvements

Daniel Kozak via Digitalmars-d digitalmars-d at puremagic.com
Thu Mar 10 10:49:28 PST 2016



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)


More information about the Digitalmars-d mailing list