www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Instructions for selecting another GC

reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
At DConf 2019 someone mentioned that the GC-implementation can 
now be replaced without recompiling the compiler. How is this 
accomplished? Is this documented?
Jun 07 2019
next sibling parent reply KnightMare <black80 bk.ru> writes:
On Friday, 7 June 2019 at 17:40:05 UTC, Per Nordlöw wrote:

 At DConf 2019 someone mentioned that the GC-implementation can 
 now be replaced without recompiling the compiler. How is this 
 accomplished? Is this documented?


r u mean this one? https://dlang.org/spec/garbage.html#gc_config
Jun 07 2019
parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Friday, 7 June 2019 at 17:52:14 UTC, KnightMare wrote:

 r u mean this one? https://dlang.org/spec/garbage.html#gc_config


No, I'm talking about being able to select a completely different 
GC during build time or run-time of my _application_, and not 
having to rebuild the D compiler.
Jun 07 2019
parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Friday, 7 June 2019 at 17:57:31 UTC, Per Nordlöw wrote:

 No, I'm talking about being able to select a completely 
 different GC during build time or run-time of my _application_, 
 and not having to rebuild the D compiler.


At 49:09 here

https://www.youtube.com/watch?v=OsOfTVm2ExY&feature=youtu.be&t=2949

Rainzer Schütze mentions the "Open GC Registry". Does he mean 
that another GC can be selected without rebuilding the compiler?
Jun 07 2019
next sibling parent Seb <seb wilzba.ch> writes:
On Friday, 7 June 2019 at 18:01:46 UTC, Per Nordlöw wrote:

 On Friday, 7 June 2019 at 17:57:31 UTC, Per Nordlöw wrote:

 No, I'm talking about being able to select a completely 
 different GC during build time or run-time of my 
 _application_, and not having to rebuild the D compiler.


 At 49:09 here

 https://www.youtube.com/watch?v=OsOfTVm2ExY&feature=youtu.be&t=2949

 Rainzer Schütze mentions the "Open GC Registry". Does he mean 
 that another GC can be selected without rebuilding the compiler?


See e.g. https://dlang.org/changelog/2.085.0.html#gc_precise for 
more details.
Jun 07 2019
prev sibling next sibling parent KnightMare <black80 bk.ru> writes:
 At 49:09 here
 https://www.youtube.com/watch?v=OsOfTVm2ExY&feature=youtu.be&t=2949


so, the main course is RefCounting with GC for removing cycles.. 
as Swift do for a long time with Apple as maintainer (not for 
Windows yet)
Jun 07 2019
prev sibling parent reply kinke <noone nowhere.com> writes:
On Friday, 7 June 2019 at 18:01:46 UTC, Per Nordlöw wrote:

 Rainzer Schütze mentions the "Open GC Registry". Does he mean 
 that another GC can be selected without rebuilding the compiler?


Rebuilding the compiler shouldn't be necessary, but now you don't 
need to rebuild druntime either and can link your custom GC 
directly into your binary and instruct druntime to use it:
https://dlang.org/spec/garbage.html#gc_registry
Jun 11 2019
parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Tuesday, 11 June 2019 at 19:41:00 UTC, kinke wrote:

 Rebuilding the compiler shouldn't be necessary, but now you 
 don't need to rebuild druntime either and can link your custom 
 GC directly into your binary and instruct druntime to use it:
 https://dlang.org/spec/garbage.html#gc_registry


Ok, great.

So something like


import core.gc.gcinterface, core.gc.registry;
import segregated_gc;

extern (C) pragma(crt_constructor) void registerSegregatedGC()
{
     registerGCFactory("segregated", &createSegregatedGC);
}

GC createSegregatedGC()
{
     __gshared instance = new SegregatedGC;
     instance.initialize();
     return instance;
}

/* The new GC is added to the list of available garbage 
collectors that can be
  * selected via the usual configuration options, e.g. by 
embedding rt_options
  * into the binary:
  */
extern (C) __gshared string[] rt_options = 
["gcopt=gc:segregated"];


works for me to hardcode the GC by linking my app with 
https://github.com/nordlow/phobos-next/blob/de1bdaaeac839cbfc65dd8bc7714128f657c19da/benchmarks/gc-benchmark/source/register_segregated_gc.d

But in my test suite (at 
https://github.com/nordlow/phobos-next/blob/de1bdaaeac839cbfc65dd8bc7714128f657c19da/benchmarks/g
-benchmark/test.sh) doing

     dub run --build=release-nobounds -- 
--DRT-gcopt=gc:conservative
     dub run --build=release-nobounds -- --DRT-gcopt=gc:precise
     dub run --build=release-nobounds -- --DRT-gcopt=gc:segregated

I don't want to hardcode the `gc:segregated`. Therefore I comment 
out the line

     extern (C) __gshared string[] rt_options = 
["gcopt=gc:segregated"];

. But then the last call to

     dub run --build=release-nobounds -- --DRT-gcopt=gc:segregated

fails as

     No GC was initialized, please recheck the name of the 
selected GC ('segregated').

How do I make a custom GC accessible without hardcoding it to be 
default and instead being able to select it a run-time via the 
parameter `--DRT-gcopt`?

The above mentioned test can be called by running it locally as

     ./test.sh
Jun 12 2019
parent reply kinke <kinke gmx.net> writes:
On Wednesday, 12 June 2019 at 12:40:12 UTC, Per Nordlöw wrote:

     dub run --build=release-nobounds -- 
 --DRT-gcopt=gc:segregated

 fails


Try building separately and not using dub to run the executable.
Jun 12 2019
parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Wednesday, 12 June 2019 at 14:22:08 UTC, kinke wrote:

 Try building separately and not using dub to run the executable.


I found a solution at

https://github.com/nordlow/phobos-next/blob/52ea7c685fdad3ded9a29fca15cd525b43aeb204/benchmarks/gc-benchmark/test.sh
Jun 19 2019
prev sibling parent SeanArbogast <marilyn.christian yandex.com> writes:
Speaking about the main opportunities to make sure in the 
mentioned software, it is necessary to check the modern ones.
Jun 11 2019