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

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

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.

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?

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.

> 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)

Speaking about the main opportunities to make sure in the mentioned software, it is necessary to check the modern ones.

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

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/gc-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

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.