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.
