• Per =?UTF-8?B?Tm9yZGzDtnc=?= (12/12) Sep 30 2018 I'm gonna play around with creating a GC that alleviates some of
• Basile B. (15/28) Sep 30 2018 The immediate idea (and maybe naive too) is to link once against

Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:

I'm gonna play around with creating a GC that alleviates some of 
the uses described in

https://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html

What's the most effective way of incrementally developing a new 
pluggable GC for druntime with regards to prevention of 
really-hard-to-find-bugs?

I'm aware of the run-time flag added in 2.072:

https://dlang.org/changelog/2.072.0.html#gc-runtimeswitch-added

Is it inevitable to rebuild druntime everytime I make an update 
to a new GC? Is so what's the preferred way of selecting a 
modified druntime in a standard installation of dmd on a Linux 
system (Ubuntu 18.04 in my case). Will Digger makes things easier?

Basile B. <b2.temp gmx.com> writes:

On Sunday, 30 September 2018 at 09:40:10 UTC, Per Nordlöw wrote:
 I'm gonna play around with creating a GC that alleviates some 
 of the uses described in

 https://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html

 What's the most effective way of incrementally developing a new 
 pluggable GC for druntime with regards to prevention of 
 really-hard-to-find-bugs?

 I'm aware of the run-time flag added in 2.072:

 https://dlang.org/changelog/2.072.0.html#gc-runtimeswitch-added

 Is it inevitable to rebuild druntime everytime I make an update 
 to a new GC?

No.

 Is so what's the preferred way of selecting a modified druntime 
 in a standard installation of dmd on a Linux system (Ubuntu 
 18.04 in my case). Will Digger makes things easier?

The immediate idea (and maybe naive too) is to link once against 
a new GC that follows the interface but has assignable handlers. 
Once DMD build, you can just do

     dmd -unittest temp_gc_handlers.d && ./temp_gc_handlers

At each iteration. temp_gc_handlers.d would have a static module 
ctor that assigns its content to the GC handler.

Once good you put the handler code in the real GC. I think that 
it would be possible that a few runtime stuff leak until the 
devel be almost complete but that doesn't matter if stuff are 
checked, let's say, from a checkpoint that says "from here this 
amount of leak is normal, it should disappear automatically in 
the real GC".

But again, this method is very hypothetical.